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