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

[Peter Hildebrandt]

Peter,

thanks for your pointers.  Just to clarify things, I am working with the  
latest SBCL on linux (ubuntu 7.10, gtk 2.2) mostly from slime.  I do not  
have other environments around for testing.

> I see that the entire main loop in gtk-app is surrounded in
> with-gdk-threads, but nothing on a finer grain. Is this the problem?

Actually from what I understand this is perfectly fine (and most C sample  
code on the net seems to do the same).  During normal use, the thread will  
spend its time within gtk-main, and gtk-main apparently releases the lock  
on idle and reacquires it when calling a callback.  So this is fine.

> It has been about a year since I've worked with cells-gtk (Not that I
> don't like it, or have given up on it.  I'm just busy with some
> server stuff and hunchentoot).

That's good to hear.  Especially now that threading appears to work (at  
least with SBCL in linux), it makes a great development environment for  
local GUI apps.  Just another example:

;; first create an empty window
(make-be 'window :title "Some Window" :kids (c-in nil))
;; the window shows up and is empty

;; next make a button and see what happens
(setf (kids *) (list (mk-button :label "click me" :on-clicked (callback (w  
e d) (print 'clicked)))))

;; for extra points: click on it

>> Now I have poked around the code for a while, and did not find any
>> of those.  Does cells-gtk use "Idles, timeouts, and input
>> functions"?  If yes, where?
>
> I did a quick tutorial at
> http://www.gtk.org/tutorial1.2/gtk_tut-17.html

Thanks, now I understand a little better what this is all about anyway.

> widgets.lisp timeout-add.

(defun timeout-add (milliseconds function)
...
                 (let ((r (with-gdk-threads
			  (funcall function))))
...

... and interestingly timeout-add actually uses with-gdk-threads ...

> This is used in test-gtk/test-display... In
> fact I have noted that this test doesn't work in some lisps! I don't
> see in my notes where though.

... and this one works perfectly in its thread for me in SBCL/linux.

> Under lispworks, gtk-app does a process-wait-with-timeout.

That should not hurt, though, since there is no callback, and thus no gtk  
access.

> Grep on idle and input doesn't show anything.

>> My second question:  Is there somewhere a list of all windows that
>> have been created using to-be?  Or will I have to hack my own using
>> :after methods?  (for details why I need this, see below)
>
> Maybe Kenny Tilton could answer that one.

 From what I can see the cells code does not keep book of the instances of  
a particular kind.  Come to think of it, I don't know why it should. (I  
see a count-it macro, but I guess this is for performance monitoring)

I included an :after method for md-awaken and a :before mtehod for  
not-to-be, specialising on window.  Now all windows created after  
start-app-in-thread are terminated when the main window is closed.

>> of the status quo.  Test-gtk works perfectly.
> Including the pulse behavior in test-display?

As mentioned above, yes it does.

>> Three limitations apply:
>>
>> (1) To maintain compatibility with start-app's behavior, the window
>> started by start-app-in-thread serves as the applications main
>> window -- gtk-main will exit, when this one is closed.  The
>> application (or the developer at the REPL) has to make sure all
>> windows created by to-be are closed using not-to-be before the main
>> window exits.  If he doesn't, they will remain inactive, until a
>> new application is started.  (This is where a list of all open
>> windows would come in handy, the solution being only a mapcar away)
>
> This may resolve the problem I've seen where I'd have to restart lisp
> to get cells-gtk unstuck after breaking (e.g. in debugger) and
> quitting. That would be marvelous!

Indeed.  This sounds exactly like the problem I had to work around here.   
I included a handler for general Lisp errors, which shows the error in a  
message box and allows you to shutdown your app cleanly or just continue  
in the main loop.  This is nice if for instance you setf a slot to an atom  
while your prog expects a list or the like.  Just correct it and click yes  
to go on as if nothing ever happened.

Regards,
Peter