[cells-gtk-devel] terminate-gtk

[Peter Hildebrandt]

Peter Denno wrote:
> Hi Peter,
> 
> So is there a way now to stop Cells-gtk? I have a Lispworks 
> application for which I make a .exe, and on quitting, the linux 
> process does not end. I have to use the linux kill command.
> 

Sorry for the late response.  I have been tied up in other issues, and 
only got back to my project yesterday.

The issue here is that GTK only wants to accept calls to gtk-main from 
one thread per process, and there appears to be no way around that. 
That means that the GTK thread has to run as long as the lisp process 
itself.

This puts us in an unfortunate situation:

- If we kill the GTK thread when the main window is closed, we'd have to 
restart out lisp process for every test run (which, of course, is not 
ideal).

- If we leave the GTK thread running, the lisp process never quits 
because of the active thread.

I am not sure what would be the right way to deal with this.  So far, I 
have only used threading while developing my application and disabled it 
before creating an executable (That is, I used start-win during the 
debugging process and changed it to start-app before creating the actual 
application).  Thus I circumvented the issue.

There a two problems with an explicit call to terminate-gtk:

(1) We do not want to call it during the debugging -- Thus we'd always 
have to comment/uncomment the call, use a parameter, use a feature, etc. 
  This is not too hard, but messy.

(2) It is non-trivial to put this call in the right place (which is why 
I vaguely said it was "ill-conceived").  If the gtk-main thread is 
terminated prematurely, the user is left with non-reactive "zombie 
windows".  If I remember correctly, it is in particular not a good idea 
to call terminate-gtk in any gtk callback (like for instance on-destroy, 
on-clicked for the Quit menu option etc.)

The right way to deal with it would be to have the gtk main-loop in 
gtk-app.lisp deal with the situation.  This is currently an infinite 
loop, calling gtk-main, wait until it returns whenever a window is 
closed, and call it again right away.

What we'd want to do is check whether there are open windows left when 
gtk-main returns, and if not, manually process all pending events and 
then return from the thread.

We'd have to options to deal with the debugging mode

(1) Just open a window when you start your debugging session: (start-win 
'window) And keep it around until you are done

(2) Have a flag (a special variable) which controls the exit behavior of 
  the main loop

Probably I won't get around to this until next week.

Peter

On a different note, cells-gtk3 is coming along, and I hope I can commit 
a first usable version for testing to the cells cvs soon.  Currently the 
cells-tree-view is still broken and I have not started porting the 
drawing-area from cells2 to cells3.

If anyone wants to play, let me know and I will zip up what I have here.

> Thanks.
> 
>> Peter
>>
>> Peter Denno wrote:
>>> Hi,
>>>
>>> gtk-app.lisp in CVS HEAD contains this:
>>>
>>> (defun stop-gtk-main ()
>>>        "Final clean up stuff -- need to RESTART lisp to access
>>> gtk again."
>>>        (terminate-gtk)
>>>        (threads:destroy-thread gtk-main-thread))
>>>
>>> I don't see terminate-gtk anywhere.
>