Summary of recent changes to cl-gtk2 in git
January 25, 2010
Minimum version checking
When loading cl-gtk2, it now checks for Gtk+ version and raises a compile-time error Gtk+ version is too old and is not supported by cl-gtk2. I’ve had several questions about errors during loading cl-gtk2 when the Gtk+ is old. Now it should be immediately clear and will note require decrypting much less comprehensible error messages about missing functions.
Support for multiple Gtk+ versions
There is now some support for several Gtk+ versions. Upon loading, cl-gtk2 pushes symbols to
*features* that allow to conditionally compile or not compile bindings for particular classes/methods/functions depending on versions of libraries. This means that while minimum supported Gtk+ version is 2.16, methods and classes from Gtk+ 2.18 will be available to you (of course, this requires writing bindings to them – I haven’t yet written complete bindings to Gtk+ 2.16 or Gtk+ 2.18). But the way this is implemented (by using reader conditionals) requires to recompile cl-gtk2 when Gtk+ is updated.
Improvements to gtk demo
I’ve improved the gtk demo a bit. Now it looks like a text page with links to various demos.
Improvements to main loop handling
I’ve made ensure-gtk-main/within-main-loop/leave-gtk-main/join-gtk-main more consistent between multi-threaded lisps and unithreaded lisps.
The suggested use for them is the following. In the ‘main’ function you have code like this:
(within-main-loop (your-application-code) ;; somewhere in your application you call leave-gtk-main ) (join-gtk-main)
E.g., to call the cl-gtk2 demonstration in this way, you just call:
(progn (gtk-demo:demo) (gtk:join-gtk-main))
This code will finish when the application quits the main loop, thereby quitting the application. This will work in multi-threaded and non-multi-threaded lisps.
In multi-threaded lisps, during development you can use within-main-loop (without join-gtk-main) to start the application in the background thread and do the development while the application is running.
Fixing the finalizing of GBoxed instances by making finalization of them thread-safe
That was one of rare-occuring bugs (at least for me) so this bug slipt past me. But now I’ve fixed it, and random crashes occur less often.