[cells-gtk-devel] start-app and multithreading?

[Peter Hildebrandt]

Kenny and Peter,

thanks for your response.

On Tue, 04 Dec 2007 17:57:47 +0100, Peter Denno <peter.denno at nist.gov>  
wrote:

>> I usually structure my applications with a "system" instance at the
>> top, system being a family subclass, each child being a window. Or
>> I go further and have system be a tree of applications of windows.
>> That sort of thing. If I was doing a network app I would extend
>> that to model a bigger world. Anyway, then new windows are made at
>> the repl with:
>>
>>    (push (my-new-window) (kids *sys*))
>>
>> Where I have bound the system instance to *sys*.

Sounds extremely reasonable.  I guess that's what I will do in my  
application.

> Come to think of it you could call,
>
> (depth-first-search <root-window> #'fail #'kids :do #'(lambda (k)
> (push k <whatever>)))
>
> at any point, and <whatever> would contain the list of all widgets
> found through navigating the kids slot.
>
> #'depth-first-search and #'fail are in pod-utils. It is part of the
> distribution.

I wonder whether this is really what one wants in a gui toolkit.   
Cells-gtk should simply find all windows and get rid of them, s.t. no  
inactive ones remain.  The approach above would miss windows which are  
created by plainly using (make-be 'window).

Is there anything wrong with hooking into md-awaken/not-to-be?  I put the  
following in my code:

(let ((open-windows nil))
   (defmethod md-awaken :after ((self window))
     (pushnew self open-windows))
   (defmethod not-to-be :before ((self window))
     (setf open-windows (delete self open-windows )))
   (defun not-to-be-all ()
     (mapcar #'not-to-be open-windows)
     (setf open-windows nil)))

where not-to-be-all is called when the user closes the main window.   
Appears to be working perfectly.  Am I missing something?

Checked creating a dozen windows, closing some with Alt-F4, some with  
menu-close, some with the close box, and having the main app (test-gtk,  
surprise, surprise) take the rest down with it.

>> The other way I have been known to get to all windows is to use
>> some hook offered by the windowing API, but I do not know if GTk
>> offers such a beast.

I'll keep that one in mind, in case the former approach fails.

>> As for the rest, yes, many times I have wrestled with the different
>> world view held by the C developer to get to the point where I can
>> do iterative development in Lisp calling a C windowing library that
>> expects to get a fresh process with each run. Obviously a
>> make/break deal for us Lispniks, and it can indeed require detailed
>> analysis of the internals of the target platform, especially at the
>> edges where we are creating and disposing of windows. It took me
>> more than a few hours to sort out the various sequences of
>> messages/events arising during the various ways a window can be
>> closed, such as by the user clicking the close box vs the
>> application initiating a close in response to alt-F4 vs etc etc
>> So you all are on the right track, don't get discouraged, use as
>> much duct tape as you need to get to interactive development.

Glad to hear that I'm not alone.  Actually it is strange anyone would give  
up and settle for any other type of UI development.  This is so much fun,  
like I'm not merely poking around in the internals of my application while  
it is running, I can watch even watch it react.  Kinda like when I pulled  
those cylinder heads on my 1962 Cadillac a couple years ago.

>> And
>> to be honest, if certain nasty combinations arise and force a
>> complete bounce of my Lisp once a day I just get on with it. :)
:)

Regards,
Peter

>> kt
>