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.
_______________________________________________
cells-gtk-devel site list
cells-gtk-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-gtk-devel
