[mcclim-devel] possible buglet in highlighting shapes

[Duncan Rose]

Having rapidly checked the spec...

On Thursday, April 28, 2005, at 12:36 AM, Andy Hefner wrote:

> On 4/27/05, Duncan Rose <duncan at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: glimpse.lisp
Type: application/octet-stream
Size: 6942 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050428/59d76d2d/attachment.obj>
-------------- next part --------------


> </grumble>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>