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

[Peter Hildebrandt]

On Tue, 04 Dec 2007 20:05:11 +0100, Peter Denno <peter.denno at nist.gov>  
wrote:
>> I wonder whether this is really what one wants in a gui toolkit.
>> Cells-gtk should simply find all windows
>
> I'm not sure what you mean by "find all windows" but if you mean find
> all widgets starting at some parent, where by parent I mean the
> relationship specified by the kid slot, I see no reason not to do the
> above.

Sorry, I am afraid I've caused a misunderstanding here.  There are two  
separate issues

(1) An application should somehow keep track of the windows it creates and  
make sure they get closed properly, unsaved data stored, etc.  This can  
nicely be done using a family tree as Kenny described, and some tree  
search (like the one you mentioned) would do the trick.

(2) However, if the programmer for some reason fails to do that (or if I  
have been just playing around at the repl, creating random windows to try  
things out), the should be some sort of safety net within the gui toolkit  
to make sure that closing the main application window does the logical  
thing, namely not leave unreactive, greyed out windows behind -- which is  
what happens once gtk-main closes down.  Therefore by "all" I mean all  
windows created after start-app-in-thread was called.

I wanted to imitate the behavior of start-app, which closes down its gtk  
communication when the main window is closed.  And even if the programmer  
forgets about closing some window he might have opened, the toolkit should  
take care.

Currently the line of events is

start-app-in-thread
   cells-gtk-init
   make-instance application
   enter gtk-main
...
open and close what ever other windows you'd like
...
until the application window is closed (either by the user or by not-to-be)
   gtk-main exits
   all windows which are still open (and would become dead) are closed
   gtk is cleanly left, but with the option for re-entry

...

start-app-in-thread again
etc.

Another approach would be to keep gtk-main running until all windows in  
the current lisp session are closed.  However, it would require some more  
investigation to see when and how gtk-main would need to be restarted to  
simulate a continous running gui.  One problem I ran into already is that  
an app like test-gtk needs cells-gtk-init to run before it can be  
relaunched -- which would take down other stuff open at the time.

>> 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).
>
> Not sure why you'd want to do that, but then I've been away from this
> code for too long.

Just to try stuff out from the repl; make a window, push some kids in  
there, change options, see what happens.

>
>>
>> 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?
>
> Looks OK to me, but I might not be the best person to ask, at this
> point.
>
> Anyone?

It'd like to hear some comments, too.


>> 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.
>
> I'm with ya there. I always wondered whether others who hacked code
> with enthusiasm did this sort of thing too.

Like peeling apart the internals of a running system or like working on  
the internals of mechanical engines?

Regards,
Peter