The current implementation of `menu-choose' lacks a fair bunch of spec-defined functionality (labels, some menu item types, scrollbars), and it often creates menus that are larger than the screen, or partially off-screen. This patch rectifies these problems - I have been running with it for 6+ months and it has worked perfectly, even though some of the code is not the prettiest in the world (my CLIM-fu has been weak). There should be no functionality regressions compared to the current version.
I know that McCLIM is currently in a freeze period, but this patch has been lying on my harddrive for too long - others may find it useful, and I would like it to be cleaned up (if necessary) so it could be included in some future release. :-)
On 7/7/06, Troels Henriksen athas@sigkill.dk wrote:
The current implementation of `menu-choose' lacks a fair bunch of spec-defined functionality (labels, some menu item types, scrollbars), and it often creates menus that are larger than the screen, or partially off-screen. This patch rectifies these problems - I have been running with it for 6+ months and it has worked perfectly, even though some of the code is not the prettiest in the world (my CLIM-fu has been weak). There should be no functionality regressions compared to the current version.
Sounds good, but I still think we should really get rid of menu-choose.lisp at some point and reuse the implementation of menus in menu.lisp, which is (was?) much more complete. It seems silly maintaining two separate implementation of menus. It might be that some of menu-choose.lisp never really goes away due to the need to support menu-choose-from-drawer, but it is much lower level and does not need to need to understand CLIM menu items anyway.
I know that McCLIM is currently in a freeze period, but this patch has been lying on my harddrive for too long - others may find it useful, and I would like it to be cleaned up (if necessary) so it could be included in some future release. :-)
You raise an interesting question - is McCLIM still in freeze? I've been proceeding as though it were not, as no one is actively working toward preparing a release.
"Andy Hefner" ahefner@gmail.com writes:
Sounds good, but I still think we should really get rid of menu-choose.lisp at some point and reuse the implementation of menus in menu.lisp, which is (was?) much more complete.
AFAIK, menu.lisp is mostly concerned with command menus, and I believe tt would make more sense to build these via the facilities provided by `menu-choose' than the other way around. If nothing else, because `menu-choose' supports a huge amount of options that would be quite difficult to support unless it is built into the basic implementation.
In any case, I think you are right that there needs to be some cleanup, but still, my patch adds support for some stuff not currently supported, without being invasive or in any way hindering any future unification of menu.lisp and menu-choose.lisp.
"Andy Hefner" ahefner@gmail.com writes:
You raise an interesting question - is McCLIM still in freeze? I've been proceeding as though it were not, as no one is actively working toward preparing a release.
From #lisp:
<Athas> When does the McCLIM freeze period stop? <antifuchs> Athas: very good question. counter-question: can we release mcclim as-is, or should we try for a re-freeze in a few weeks?
I don't think anyone knows. :-)
"TH" == Troels Henriksen athas@sigkill.dk writes:
TH> "Andy Hefner" ahefner@gmail.com writes: [...snip...]
>> You raise an interesting question - is McCLIM still in freeze? >> I've been proceeding as though it were not, as no one is >> actively working toward preparing a release.
>> From #lisp:
TH> <Athas> When does the McCLIM freeze period stop? <antifuchs> TH> Athas: very good question. counter-question: can we release TH> mcclim as-is, or should we try for a re-freeze in a few weeks?
TH> I don't think anyone knows. :-)
I have had some fairly extensive problems with using scrolling panes, that I think should either be dismissed as me doing something weird, an ACL-specific bug, or fixed, before a release.
Suggestion: I think one could test this possible bug by trying to use the class browser in a scrolling window (it does scroll, doesn't it?) in the listener. If someone would have a look and see if the scrolling window correctly starts scrolling when the class graph grows, that would establish that it's something I'm doing that's bad or an ACL-specific bug (ACL's MOP doesn't work with the listener, so it's not easy for me to do this test myself).
Cheers, R
rpgoldman@real-time.com writes:
Suggestion: I think one could test this possible bug by trying to use the class browser in a scrolling window (it does scroll, doesn't it?) in the listener. If someone would have a look and see if the scrolling window correctly starts scrolling when the class graph grows, that would establish that it's something I'm doing that's bad
Do you mean the Show Class Subclasses/Superclasses commands? If so, class graphs seem to scroll fine with the latest McCLIM CVS sources and CMUCL Snapshot 2006-06 (19C) under Slackware Linux.
Paolo
On 7/7/06, Troels Henriksen athas@sigkill.dk wrote:
"Andy Hefner" ahefner@gmail.com writes:
Sounds good, but I still think we should really get rid of menu-choose.lisp at some point and reuse the implementation of menus in menu.lisp, which is (was?) much more complete.
AFAIK, menu.lisp is mostly concerned with command menus, and I believe tt would make more sense to build these via the facilities provided by `menu-choose' than the other way around. If nothing else, because `menu-choose' supports a huge amount of options that would be quite difficult to support unless it is built into the basic implementation.
Perhaps. 2/3 of menu.lisp is a generic implementation of menus as gadgets, not relating to command menus specifically. frame-manager-menu-choose is intended to allow use of native window system menus, and in that respect using the menu.lisp implementation seems just as valid as throwing a bunch of presentations in a stream-pane. On the other hand it is true that not all of the keywords to menu-choose translate, particularly those relating to table formatting, but I don't think it would be a terrible amount of work to support these using a table-pane. Others, such as those related to caching, seem ignorable.
Maybe it makes sense to implement them the other way around (command menus in terms of menu-choose). Maybe it doesn't. Menus have some gadget-like characteristics (such as opening submenus) that we could in theory implement as presentation actions. There is some sense in choosing the simplest implementation strategy that can support the required features, and on X11 there is no specific reason to prefer a gadget-based approach simply because it most closely resembles how other toolkits are implemented. However, I have doubts about the user experience resulting from more clever implementations that try to leverage higher level CLIM features. My general opinion is that the higher you ascend the CLIM stack, the more bogus and unfinished the design gets, and the more of a fight against the system it becomes to get specific desired behaviors.
I personally dislike the menu-choose.lisp menus because they don't feel tolerably 'native', even to the lowered expectations of an X11 user. Finding a way to hack the highlighting style to look like a normal menu (I've never been a fan of the CLIM "draw a box around it" highlighting) would be an improvement. I have reservations about an approach that likely requires defining gestures and using presentation actions to implement the required behavior. You might be able to define a presentation action that opens a submenu in response to the select gesture, but how do I get the traditional behavior where submenus open/close automatically in response to mouse motion, short of dropping down to writing event handlers?
Fortunately, the path of least resistance -- applying your patch and paying no further mind to the menus for another couple years -- works for me.
<antifuchs> Athas: very good question. counter-question: can we release mcclim as-is, or should we try for a re-freeze in a few weeks?
Before release, we should definitely restore the forward-referencing workarounds that Xof removed, as they're still needed for CMUCL. I have a patch against mp-nil.lisp that I'd like to get in too, and I'll probably check that in tonight. It will break gtkairo on unithread lisps, and although the patch to fix it seems trivial, I'm not enthusiastic about entering the brave new world of gtkairo in order to test it.. =/
"Andy Hefner" ahefner@gmail.com writes:
<antifuchs> Athas: very good question. counter-question: can we release mcclim as-is, or should we try for a re-freeze in a few weeks?
Before release, we should definitely restore the forward-referencing workarounds that Xof removed, as they're still needed for CMUCL.
I agree, but has anyone reported this bug to the CMUCL folks? (It might not be too much like hard work for them to fix...)
Cheers,
Christophe
Christophe Rhodes wrote:
"Andy Hefner" ahefner@gmail.com writes:
<antifuchs> Athas: very good question. counter-question: can we release mcclim as-is, or should we try for a re-freeze in a few weeks?
Before release, we should definitely restore the forward-referencing workarounds that Xof removed, as they're still needed for CMUCL.
I agree, but has anyone reported this bug to the CMUCL folks? (It might not be too much like hard work for them to fix...)
There isn't anything in the CMUCL archives. It is difficult to stay subscribed to cmucl-devel due to the amount of spam, so people might not have seen a bug report even if it had been sent.
What workaround used to be there ?
Robert Swindells
To: csr21@cam.ac.uk Date: Fri, 7 Jul 2006 21:35:18 +0100 (BST) From: Robert Swindells
There isn't anything in the CMUCL archives. It is difficult to stay subscribed to cmucl-devel due to the amount of spam, so people might not have seen a bug report even if it had been sent.
What complete and utter bullcrap! I've been on the cmucl-devel mailing list since Oct. 2002 without any difficulty. (And cmucl-imp and cmucl-bugs before that back to 95.) Yes, the list does get a couple of SPAMs a day ever since they switched to using gmane on common-lisp.net. But that certainly doesn't drown out legitimate messages.
Mike McDonald mikemac@mikemac.com
Robert Swindells rjs@fdy2.demon.co.uk writes:
Christophe Rhodes wrote:
"Andy Hefner" ahefner@gmail.com writes:
<antifuchs> Athas: very good question. counter-question: can we release mcclim as-is, or should we try for a re-freeze in a few weeks?
Before release, we should definitely restore the forward-referencing workarounds that Xof removed, as they're still needed for CMUCL.
I agree, but has anyone reported this bug to the CMUCL folks? (It might not be too much like hard work for them to fix...)
There isn't anything in the CMUCL archives. It is difficult to stay subscribed to cmucl-devel due to the amount of spam, so people might not have seen a bug report even if it had been sent.
What workaround used to be there ?
I believe if you try to compile mcclim under current CMUCL (using mcclim.asd) you will get an error about a layout being invalid (or some such similar message). The error disappears if, in protocol-classes.lisp, the definition of the DESIGN class is moved to above the first time it is referenced as a superclass (by the REGION protocol class).
http://common-lisp.net/cgi-bin/viewcvs.cgi/mcclim/protocol-classes.lisp?root=mcclim&r1=1.2&r2=1.3 shows the mcclim diff which exposes the problem. It's possible, though I'm not sure, that the patch which fixed the similar problem in SBCL was merged as version sbcl-0.9.10.27 (that codepath was subsequently modified in sbcl-0.9.11.45).
(CMUCL no longer runs on any machine I have access to, so I can't test anything.)
Cheers,
Christophe
Quoting Andy Hefner (ahefner@gmail.com):
workarounds that Xof removed, as they're still needed for CMUCL. I have a patch against mp-nil.lisp that I'd like to get in too, and I'll probably check that in tonight. It will break gtkairo on unithread lisps, and although the patch to fix it seems trivial, I'm not enthusiastic about entering the brave new world of gtkairo in order to test it.. =/
Well, I will test that patch if you send it to me. (However, I will be offline for two weeks starting Monday.)
I know some are considering non-threaded CLIM broken by design and not worth putting much effort into, but personally I like it a lot. :-)
d.
On 7/8/06, David Lichteblau david@lichteblau.com wrote:
Well, I will test that patch if you send it to me. (However, I will be offline for two weeks starting Monday.)
I know some are considering non-threaded CLIM broken by design and not worth putting much effort into, but personally I like it a lot. :-)
Great. The patch adds support for :timeout 0 to get-next-event. This looks like it should work:
Index: event.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/gtkairo/event.lisp,v retrieving revision 1.8 diff -r1.8 event.lisp 102a103,108
((and (numberp timeout) (zerop timeout)) (gtk-main-iteration port nil) (dequeue port)) ((number timeout) (error "Timeout must be zero or nil"))
"Andy Hefner" ahefner@gmail.com writes:
Before release, we should definitely restore the forward-referencing workarounds that Xof removed, as they're still needed for CMUCL. I
The latest McCLIM CVS sources build and work fine for me with CMUCL Snapshot 2006-06 (19C) on Slackware Linux.
Paolo
-
Andy Hefner -
Christophe Rhodes -
David Lichteblau -
Mike McDonald -
Paolo Amoroso -
Robert Swindells -
rpgoldman＠real-time.com -
Troels Henriksen