Having rapidly checked the spec...
On Thursday, April 28, 2005, at 12:36 AM, Andy Hefner wrote:
On 4/27/05, Duncan Rose duncan@robotcat.demon.co.uk wrote:
Also things like specifying an :application pane type in the :panes of an application frame, passing ':scroll-bars t' but not having the pane
<grumble> Can you find where in the spec this is required? I think this keyword is fictional, and I'm astonished at the number of people trying to use it. Maybe it is a vendor extension, but it doesn't make any sense to me. Scrolling is acheived by embedding the pane in another pane which
You are right; it's not in the spec. I'm actually quite suprised I didn't already know this considering how much time I've spend reading the thing ;-) I'll make an excuse that I haven't read chapter 29 in as much detail as some of the others...
Speaking purely personally, when I'm trying to struggle through a mysterious coding exercise, and printed docs make less sense than they could, I try to find a canonical (existing) application from which to copy and go for the 'it works for application XXX, why not me?'. In this case there's only one canonical application in my opinion (I choose to discount the address book demo). Can you guess which it is?
Here's it's define-application-frame form:
;;; Listener application frame (define-application-frame listener (standard-application-frame command-history-mixin) ((system-command-reader :accessor system-command-reader :initarg :system-command-reader :initform t)) (:panes (interactor :interactor :scroll-bars T :display-function #'listener-initial-display-function :display-time t) (doc :pointer-documentation) (wholine (make-pane 'wholine-pane :display-function 'display-wholine :scroll-bars nil :display-time :command-loop :end-of-line-action :allow))) (:top-level (default-frame-top-level :prompt 'print-listener-prompt)) (:command-table (listener :inherit-from (application-commands lisp-commands filesystem-commands show-commands) :menu (("Application" :menu application-commands) ("Lisp" :menu lisp-commands) ("Filesystem" :menu filesystem-commands) ("Show" :menu show-commands)))) (:disabled-commands com-pop-directory com-drop-directory com-swap-directory) (:menu-bar t) (:layouts (default (vertically () interactor doc wholine))))
I suggest if you want to see this option used less often, it should NOT be present here. Even if the :scroll-bars is left out, the application pane gets a scroll bar drawn in it, which then appears to be unusable. Could well be another user error though...
provides scroll bars and a viewport. If I expect :scroll-bars t to work as expected, make-pane would have to return the scroller pane rather than the the pane I asked it to create (which makes no sense at all), or there would have to be some magic backdoor whereby adopting my pane caused a chain of parents to be adopted in its place.
Sort of like the way every frame contains a raised pane with a menu pane in it, even if they never get used? I agree, it's annoying ;-)
I've attached a little utility I'm calling 'glimpse' at the moment; fire it up ('glimpse:glimpse' after building) and 'show sheet hierarchy' (hopefully it will work; it's a quick and nasty hack but might grow into more sometime. Perhaps others will find it interesting).
I don't much like that either (if I was modifying the UI dynamically, with a bunch of gadgets in a container, I'd no longer know which one to disown when its time came without walking the entire tree of children).
I have heard this complaint so often now that it is tempting to add a check which will yell at programmers who expect this to work.
Just take the code out of the listener and its use will probably disappear.
-Duncan
</grumble> _______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel