From athas at sigkill.dk  Fri Jul  7 15:52:30 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 07 Jul 2006 17:52:30 +0200
Subject: [mcclim-devel] Patch for menu-choose.lisp
Message-ID: <8764i91kg1.fsf@sigkill.dk>

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. :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: menu-choose.lisp.patch
Type: text/x-patch
Size: 18863 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060707/4cab1629/attachment.bin>
-------------- next part --------------

-- 
\  Troels "Athas"
/\ Henriksen

From ahefner at gmail.com  Fri Jul  7 17:19:39 2006
From: ahefner at gmail.com (Andy Hefner)
Date: Fri, 7 Jul 2006 13:19:39 -0400
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <8764i91kg1.fsf@sigkill.dk>
References: <8764i91kg1.fsf@sigkill.dk>
Message-ID: <31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>

On 7/7/06, Troels Henriksen <athas at 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.


From athas at sigkill.dk  Fri Jul  7 19:29:50 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Fri, 07 Jul 2006 21:29:50 +0200
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com> (Andy
	Hefner's message of "Fri, 7 Jul 2006 13:19:39 -0400")
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
Message-ID: <878xn51adt.fsf@sigkill.dk>

"Andy Hefner" <ahefner at 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 at 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. :-)

-- 
\  Troels "Athas"
/\ Henriksen


From rpgoldman at real-time.com  Fri Jul  7 20:13:08 2006
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Fri, 7 Jul 2006 15:13:08 -0500
Subject: [mcclim-devel] Patch for menu-choose.lisp [really freeze period]
In-Reply-To: <878xn51adt.fsf@sigkill.dk>
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
Message-ID: <17582.49236.791159.674900@necronomicon.sift.info>

>>>>> "TH" == Troels Henriksen <athas at sigkill.dk> writes:

    TH> "Andy Hefner" <ahefner at 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



From ahefner at gmail.com  Fri Jul  7 21:22:31 2006
From: ahefner at gmail.com (Andy Hefner)
Date: Fri, 7 Jul 2006 17:22:31 -0400
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <878xn51adt.fsf@sigkill.dk>
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
Message-ID: <31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>

On 7/7/06, Troels Henriksen <athas at sigkill.dk> wrote:
> "Andy Hefner" <ahefner at 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.. =/


From csr21 at cam.ac.uk  Fri Jul  7 22:15:09 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Fri, 07 Jul 2006 23:15:09 +0100
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
	(Andy Hefner's message of "Fri, 7 Jul 2006 17:22:31 -0400")
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
	<31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
Message-ID: <sqac7lcb9u.fsf@cam.ac.uk>

"Andy Hefner" <ahefner at 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


From rjs at fdy2.demon.co.uk  Fri Jul  7 20:35:18 2006
From: rjs at fdy2.demon.co.uk (Robert Swindells)
Date: Fri,  7 Jul 2006 21:35:18 +0100 (BST)
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <sqac7lcb9u.fsf@cam.ac.uk> (message from Christophe Rhodes on
	Fri, 07 Jul 2006 23:15:09 +0100)
Message-ID: <20060707203518.866A5E9D@fdy2.demon.co.uk>


Christophe Rhodes wrote:
>"Andy Hefner" <ahefner at 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


From mikemac at mikemac.com  Sat Jul  8 02:46:31 2006
From: mikemac at mikemac.com (Mike McDonald)
Date: Fri, 07 Jul 2006 19:46:31 -0700
Subject: [mcclim-devel] Patch for menu-choose.lisp 
In-Reply-To: Your message of "Fri, 07 Jul 2006 21:35:18 +0100."
	<20060707203518.866A5E9D@fdy2.demon.co.uk> 
Message-ID: <200607080246.k682kWT22250@saturn.mikemac.com>


>To: csr21 at 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 at mikemac.com


From csr21 at cam.ac.uk  Sat Jul  8 06:33:42 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sat, 08 Jul 2006 07:33:42 +0100
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <20060707203518.866A5E9D@fdy2.demon.co.uk> (Robert Swindells's
	message of "Fri, 7 Jul 2006 21:35:18 +0100 (BST)")
References: <20060707203518.866A5E9D@fdy2.demon.co.uk>
Message-ID: <sq64i8d2rd.fsf@cam.ac.uk>

Robert Swindells <rjs at fdy2.demon.co.uk> writes:

> Christophe Rhodes wrote:
>>"Andy Hefner" <ahefner at 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


From david at lichteblau.com  Sat Jul  8 09:55:43 2006
From: david at lichteblau.com (David Lichteblau)
Date: Sat, 8 Jul 2006 11:55:43 +0200
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
	<31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
Message-ID: <20060708095543.GA21862@gargravarr.knowledgetools.de>

Quoting Andy Hefner (ahefner at 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.


From ahefner at gmail.com  Sat Jul  8 17:20:15 2006
From: ahefner at gmail.com (Andy Hefner)
Date: Sat, 8 Jul 2006 13:20:15 -0400
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <20060708095543.GA21862@gargravarr.knowledgetools.de>
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
	<31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
	<20060708095543.GA21862@gargravarr.knowledgetools.de>
Message-ID: <31ffd3c40607081020x26ae60b4x33444bb2095efa19@mail.gmail.com>

On 7/8/06, David Lichteblau <david at 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"))


From amoroso at mclink.it  Sun Jul  9 11:37:36 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 09 Jul 2006 13:37:36 +0200
Subject: [mcclim-devel] Patch for menu-choose.lisp
In-Reply-To: <31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
	(Andy Hefner's message of "Fri, 7 Jul 2006 17:22:31 -0400")
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
	<31ffd3c40607071422s3b4236c2k91bde4fcf9d3fc20@mail.gmail.com>
Message-ID: <87irm7huv3.fsf@plato.moon.paoloamoroso.it>

"Andy Hefner" <ahefner at 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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From amoroso at mclink.it  Sun Jul  9 11:59:50 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 09 Jul 2006 13:59:50 +0200
Subject: [mcclim-devel] Patch for menu-choose.lisp [really freeze period]
References: <8764i91kg1.fsf@sigkill.dk>
	<31ffd3c40607071019j6ead95d6udb4b5f43af42d11@mail.gmail.com>
	<878xn51adt.fsf@sigkill.dk>
	<17582.49236.791159.674900@necronomicon.sift.info>
Message-ID: <8764i7htu1.fsf@plato.moon.paoloamoroso.it>

rpgoldman at 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
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From amoroso at mclink.it  Fri Jul 14 18:11:19 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 14 Jul 2006 20:11:19 +0200
Subject: [mcclim-devel] CLIM-STREAM-PANE bugs mentioned in CLIM guided tour
Message-ID: <87mzbcvyyg.fsf@plato.moon.paoloamoroso.it>

The version of the paper "A Guided Tour of CLIM" in McCLIM's source
tree, which I believe is updated to early 2006, states in section "A
simple drawing application":

  This is the first example that does not use clim-stream-pane (or one
  of its subclasses) as a pane class[*] [...]

  [*] When using McCLIM, we have to do this as there are bugs in the
  behavior of clim-stream-pane that have not been fixed yet.

What are these bugs?  Are they still outstanding?


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From metawilm at gmail.com  Sun Jul 23 22:56:56 2006
From: metawilm at gmail.com (Willem Broekema)
Date: Mon, 24 Jul 2006 00:56:56 +0200
Subject: [mcclim-devel] documentation fix
Message-ID: <f6bc9b490607231556o227cc7c9j6265345d3103c722@mail.gmail.com>

Hi all,

In file INSTALL there's 'asdf:load instead of 'asdf:load-op, and a
missing closing bracket. This patch fixes that.

- Willem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asdf_loadop.patch
Type: application/octet-stream
Size: 1828 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060724/e5cf7130/attachment.obj>

From rudi at constantly.at  Mon Jul 24 07:21:00 2006
From: rudi at constantly.at (Rudi Schlatte)
Date: Mon, 24 Jul 2006 09:21:00 +0200
Subject: [mcclim-devel] documentation fix
In-Reply-To: <f6bc9b490607231556o227cc7c9j6265345d3103c722@mail.gmail.com>
References: <f6bc9b490607231556o227cc7c9j6265345d3103c722@mail.gmail.com>
Message-ID: <1F156EA8-7A68-43DB-B718-DE3E142246FC@constantly.at>


On 24. Jul 2006, at 00:56, Willem Broekema wrote:

> In file INSTALL there's 'asdf:load instead of 'asdf:load-op, and a
> missing closing bracket. This patch fixes that.

Thanks, committed.

Cheers,

Rudi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060724/c0102815/attachment.sig>