[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
On 8/25/05, Max-Gerd Retzlaff <mretzlaff@common-lisp.net> wrote:
(Broken because OPEN-WINDOW-STREAM doesn't really work yet. I think there has to be a (redisplay-frame-panes frame) or something like that in its event-loop (that is the function STANDALONE-EVENT-LOOP).)
Why do you think that?
Good evening. On Thu, Aug 25, 2005 at 05:48:37PM -0400, Andy Hefner wrote:
On 8/25/05, Max-Gerd Retzlaff <mretzlaff@common-lisp.net> wrote:
(Broken because OPEN-WINDOW-STREAM doesn't really work yet. I think there has to be a (redisplay-frame-panes frame) or something like that in its event-loop (that is the function STANDALONE-EVENT-LOOP).)
Why do you think that?
In my hack of WITH-STREAM-IN-OWN-WINDOW I called OPEN-WINDOW-STREAM without specifying any parameters, in particular without specifying :INPUT-BUFFER. If that is done (or if :INPUT-BUFFER is set to nil) a separate process is made for the application frame of the opened window stream and (basically) STANDALONE-EVENT-LOOP is specified as the process's function. The problem was that inside the opened windows only about every forth or fifth mouse click or keystroke had effects. Calling REDISPLAY-FRAME-PANES inside STANDALONE-EVENT-LOOP did change this, (altough I was worried that calling REDISPLAY-FRAME-PANES in every iteration of the loop has been quite expensive). But there has been a short discussion in #lisp after Christophe mentioned that they use OPEN-WINDOW-STREAM in the Tablature Editor without problems: 23:30 < Xophe> mgr: we don't have any of those problems; on the other hand, we share an input buffer I replaced the aforementioned call in WITH-STREAM-IN-OWN-WINDOW by: (open-window-stream :label ,label :input-buffer (climi::frame-event-queue *application-frame*)) This is very nice as a) it works without the reaction problems and b) I could get rid of the ugly, ugly (delay 0.1) that "ensured" that the new-process has been created before the stream was used. Without this I consider WITH-STREAM-IN-OWN-WINDOW much less a hack. At first I was a tad unsure about using :input-buffer as Franz' CLIM 2 User Guide says on ACCEPTING-VALUES: "The remaining keyword arguments [:input-buffers being one of them] are internal and should not be used." But the CLIM II Specification just says: If input-buffer is supplied, it is an input buffer or event queue to use for the resulting window. Programmers will generally supply this when they want the new window to share its input buffer with an existing application. The default is to create a new input buffer. STANDALONE-EVENT-LOOP or the part inside of (unless input-buffer ...) of OPEN-WINDOW-STREAM should perhaps still be changed, though. And the McCLIM user's manuel should contain in its (not yet existing) paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue *application-frame*).. Bye, Max PS: I'll apply the patch to CLIMI::WITH-STREAM-IN-OWN-WINDOW soon. Comments are welcome. -- Max-Gerd Retzlaff <m.retzlaff@gmx.net> For your amusement: My apologies if I sound angry. I feel like I'm talking to a void. -- Avery Pennarun
"mgr" == Max-Gerd Retzlaff <m.retzlaff@gmx.net> writes:
mgr> And the McCLIM user's manuel should contain in its (not yet existing) mgr> paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call mgr> OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue mgr> *application-frame*).. This raises the obvious question of whether this should somehow be made the default value of that argument. Something like (when (boundp '*application-frame*) (climi::frame-event-queue *application-frame*)) perhaps? R
Hello On Thu, Aug 25, 2005 at 06:53:49PM -0500, rpgoldman@real-time.com wrote:
"mgr" == Max-Gerd Retzlaff <m.retzlaff@gmx.net> writes:
mgr> And the McCLIM user's manuel should contain in its (not yet existing) mgr> paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call mgr> OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue mgr> *application-frame*)..
This raises the obvious question of whether this should somehow be made the default value of that argument. Something like
Well, that would be against the CLIM II specification. As already quoted in my last mail it says: If input-buffer is supplied, it is an input buffer or event queue to use for the resulting window. Programmers will generally supply this when they want the new window to share its input buffer with an existing application. The default is to create a new input buffer. Bye, Max -- Max-Gerd Retzlaff <m.retzlaff@gmx.net> For your amusement: Elliptic paraboloids for sale.
"mgr" == Max-Gerd Retzlaff <m.retzlaff@gmx.net> writes:
mgr> Hello mgr> On Thu, Aug 25, 2005 at 06:53:49PM -0500, rpgoldman@real-time.com wrote: >> >>>>> "mgr" == Max-Gerd Retzlaff <m.retzlaff@gmx.net> writes: >> mgr> And the McCLIM user's manuel should contain in its (not yet existing) mgr> paragraph on OPEN-WINDOW-STREAM saying that one probably wants to call mgr> OPEN-WINDOW-STREAM with :input-buffer as (climi::frame-event-queue mgr> *application-frame*).. >> >> This raises the obvious question of whether this should somehow be >> made the default value of that argument. Something like mgr> Well, that would be against the CLIM II specification. As already mgr> quoted in my last mail it says: mgr> If input-buffer is supplied, it is an input buffer or mgr> event queue to use for the resulting window. Programmers mgr> will generally supply this when they want the new window mgr> to share its input buffer with an existing mgr> application. The default is to create a new input buffer. Um... but I thought that your earlier message said that the default behavior dictated by the spec didn't work. Maybe I didn't fully understand. I guess I had thought a spec violation was better than a spec-obeying busted behavior... If the spec-dictated behavior really *is* busted, would it be reasonable to hoist an error on defaulting the argument, and suggest that the user do the spec-defying but workable thing? Best, R
participants (3)
-
Andy Hefner
-
Max-Gerd Retzlaff
-
rpgoldman@real-time.com