Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
>> 3. why is the window not destroyed/unmapped after I choose=20
>>Menu > File > Exit in Gnome (Ubuntu Dapper)? =20
>./clisp -q -norc -K full -x '(gtk:gui "gtk2/ui.glade")'
I did full/lisp.run -M full/lispinit.mem and worked from the REPL.
With -x, I don't expect you to see the symptom, since the window will
be teared down when clisp exits.
>> 4. Did anybody ever see a clean-up callback called?
>in what situation should it be called?
I'd really like to see that specified in the GTK docs.
My expectation is that GTK does resource management. As such, it must =
user-supplied finalizers (aka destroyers). When does that happen?
E.g., if a callback where linked to a widget, I'd expect the callback =
be called when the widget is irremediably destroyed. If a signal =
not somehow "belong" to a widget, but perhaps to 2 objects, then the =
is more complicated.
I haven't observed clean-up in the glade demo. Quite to the contrary,
gtk::*callback-funcs* grows and grows.
Tomas Zellerin wrote:
>> just open "modules/gtk2/ui.glade" in glade and add callbacks.
>> gtk:gui will do all the necessary magic.
>I think I see. I just did not believe that simple writing lisp into
>callbacks could work.
You can deduce that the module or more specifically, the GTK interaction
API with Lisp is still experimental. IMHO, writing Lisp code into a
Glade XML file is not TRT.
I'd very much prefer something which preserves lexical scoping: this is
really valuable, since the callbacks for now don't provide local context
and integrates nicely into Lisp. The current way of possibly passing
args via the symbol gtk::args and READ-FROM-STRING is, well, not ideal.
Over ten years ago, I've advocated separating the GUI look from the
application, and haven't changed opinion since. Externally manipulable
representations of the layout are one path in that direction, and that's
why I like the separate UI description idea approach that Glade
implements, even though I can't comment on its details.
I think there's a need for a good mapping between the XML signal string
information and Lisp code. Maybe just a combination of resolver
function and alist?
(flet ((about #)
(wclose (widget) (gtk_destroy widget))
`(("open-about" . ,#'about)
("close-main" . ,#'wclose)))))
well, that's certainly not enough since one would like to access some
widgets via a local variable ...
BTW, there are several other GTK bindings out there. Maybe this one
should not be too different from the others -- should they (unlikely)
resemble each other.