There are still some I/O issues waiting to be resolved that affect threads (Win32 is quite weird when it comes to I/O). Lucky for me, Anton Kovalenko made improvements in SBCL’s I/O for Win32.

cl-gtk2 seems to work in multithreaded SBCL on Windows (though I didn’t test it a lot). There is an issue that affects cl-gtk2: loading it from the SLIME REPL hangs during initialization of Gtk+ due to some deadlock in windows’ C runtime – you’ll just have to enter anything in SLIME’s *inferior-lisp* buffer to unhang it. Hopefully, this will be resolved with help from Anton Kovalenko.

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.

This means that it is possible to install cl-gtk2 with the following commands at the REPL:


(asdf:oos 'asdf:load-op :asdf-install)
(asdf-install:install :cl-gtk2-gtk)
(asdf-install:install :cl-gtk2-cairo)
(asdf-install:install :cl-gtk2-gtkglext)


The primary motivation for this was the recent release of closer-mop library which breaks cl-gtk2-0.1 by causing symbol conflicts.

Other than that, there were several bugfixes and addition of binding to most parts of Gdk, see the full changelog for details.

This was done mainly to make installation and packaging easy – having a version and source tarball helps.

Also, for Gentoo Linux I’ve made an overlay with necessary ebuilds that can be installed with layman:

layman -a lisp
layman --overlays=http://github.com/dmitryvk/cl-gtk2-overlay/raw/master/layman-list.xml -a cl-gtk2

I made several changes to support CLISP (they fix my incorrect usage of CLOS MOP). cl-gtk2 runs on some versions of clisp and does not run on some others. It seems that clisp in Gentoo (I don’t know yet whether it’s distro-specific or not) is broken on amd64: callbacks do not work at all since clisp-2.47 (or maybe earlier). I’ve tested on unithreaded clisp-2.48 on Windows, and cl-gtk2 ran fine there. However, this requires checking on multi-threaded builds and on other platforms.

I’ve also improved parts of bindings: GtkTextView, GtkTreePath and GtkTreeRowReference, GtkWidget, GtkContainer child properties, GtkFileChooser, GtkHSV, GtkTextBuffer serialization, GtkTreeModelSort, GtkTreeStore, GtkListStore.

New gtk:timer class is available. Instance of this class manages a single `timeout’ – a function that is called by GLib main loop every n milliseconds.

The important addition is integration with cl-cairo2. This allows to draw on widgets with Cairo.

SBCL on windows is unithreaded only. I haven’t been able to make cl-gtk2 work if SBCL is started from SLIME (however, I haven’t tried very hard), but running from command-line works. And SBCL is experiencing some rare crashes.

Clozure CL had a bug with its CLOS MOP implementation that had only been fixed today. In order to run cl-gtk2 under Clozure, you need to have Clozure from SVN (revision 12905 or newer). Clozure works fine on windows, has threads and is quite fast. This makes CCL more useful for development or installing on Windows. But I haven’t yet added support for saving Lisp images with Clozure.UPD:Support for saving images with CCL has been added.

Using shared libraries seems more fragile on Windows (SBCL on Windows does not tolerate missing symbols like it does on Linux), and Gtk+-2.16 is a requirement for cl-gtk2.

Some obligatory screenshots: a simple text editor and rotating OpenGL teapot.

• Object denaturation. Object denaturation means that we pass a reference to an object of some type derived from GObject type but then we receive object of some other base type. E.g., we create a custom-window deriving from gtk-window with some fields containing application data. And if there are no references to custom-window and we receive a pointer to corresponding object, we receive it as a gtk-window, not custom-window.
  GObject’s toggle references are designed exactly to avoid this problem in language bindings. Toggle references let the binding know when the “foreign” side has no more references to an object (and this means that we will now never receive pointer to this object) and when the “foreign” side has some references (and may potentially pass object back to us).

• References leak. There were cases when references were leaked: the cl-gtk2-gobject increased the objects’ refcount more than it should. Several generic cases of it have been fixed (references were increased twice when receiving the pointer from foreign code for the first time; functions that return already g_object_ref’ed objects).
• Simplification of creation of GObject instances and instances of lisp-implemented GObject classes.

The changes are in git now.

But there is at least one case of reference leaking is present. Creating interface with GtkBuilder leaks some references.

To use this approach, we create the class as a subclass of desired widget:

(defclass custom-window (gtk-window)
  ()
  (:metaclass gobject-class))

In CL-GTK2, GObject classes and their subclasses must have gobject-class as their metaclass. The absence of :g-type-name class option specifies that this class is mapped to GObject class GtkWindow. This means that (make-instance 'custom-window) creates the GObject class GtkWindow and returns the custom-window instance as its wrapper. CL-GTK2 maintains references to created object instances, so you will always get back the instance of custom-window from all Gtk+ functions, methods, properties. This means that this works as you would expect it work.

Often, we want to customize the creation of widgets (by specifying their properties at construction time). This is possible with :default-initargs class option:

(defclass custom-window (gtk-window)
  ()
  (:metaclass gobject-class)
  (:default-initargs :title "Custom window"
                     :default-width 320
                     :default-height 240))

Specified default-initargs will be passed into GtkWindow‘s constructor.

Also it is possible to specify the :after method for initialize-instance that will initialize the the widget.

For example, we will have a GtkLabel and a GtkButton inside the custom-window packed into GtkVBox.

(defclass custom-window (gtk-window)
  ((label :initform (make-instance 'label :label "A label text")
          :reader custom-window-label)
   (button :initform (make-instance 'button :label "Click me!")
           :reader custom-window-button))
  (:metaclass gobject-class)
  (:default-initargs :title "Custom window"
                     :default-width 320
                     :default-height 240))

(defmethod initialize-instance :after
    ((window custom-window) &key &allow-other-keys)
  (connect-signal (custom-window-button window) "clicked"
                  (lambda (button)
                    (declare (ignore button))
                    (format t "Button clicked~%")))
  (let ((box (make-instance 'v-box)))
    (container-add window box)
    (box-pack-start box (custom-window-label window))
    (box-pack-start box (custom-window-button window) :expand nil)))

Now we can use the custom-window as a composite widget:

(within-main-loop
  (let ((w (make-instance 'custom-window)))
    (widget-show w)))

That’s the screenshot of a demo:

To build GUI, we’ll use the CL-GTK2. The process will be described step by step.

Start up Slime and load CL-GTK2:

(asdf:oos 'asdf:load-op :cl-gtk2-gtk)

Create a source file (call it hello-world.lisp) with the following content:

(defpackage :hello-world
  (:use :cl :gobject :gtk)
  (:export :main :run))

(in-package :hello-world)

(defun main ()
  (within-main-loop
    (let ((w (make-instance 'gtk-window :title "Hello, world"))
          (l (make-instance 'label :label "Hello, world!")))
      (container-add w l)
      (connect-signal w "destroy" (lambda (w)
                                    (declare (ignore w))
                                    (gtk-main-quit)))
      (widget-show w))))

(defun run ()
  (main)
  (join-main-thread))

In this source file, hello-world package is defined that exports two functions: main and run. The ‘main’ function is used during development – it launches the program in a background thread (the within-main-loop macro does that) and returns immdeiately; and the ‘run’ function is used when launching the program not from Slime (it returns only when the application is closed).

The join-main-thread function waits until the Gtk+ main loop finishes. It finishes when the window is closed and the gtk-window widget receives the “destroy” signal.

We can start the program from the Slime’s REPL:

(hello-world:main)

After you enter this expression at the REPL, Gtk+ background thread will be started and the control returns to the REPL.

Now let’s create the stand-alone program that will not require Lisp compiler and Lisp libraries on the user’s machine.

First, we define the ASDF system.

To do this, we create the hello-world.asd file at the same directory where hello-world.lisp file is located with the following contents:

(defsystem :hello-world
  :name "hello-world"
  :components ((:file "hello-world"))
  :depends-on (:cl-gtk2-gtk))

This definition specifies the way of building the program: first load the cl-gtk2-gtk system and load the hello-world.lisp source file.

Usually ASDF system definitions are used to define systems that contain code of libraries and are placed (in Linux) into system-wide directory /usr/share/common-lisp/systems. But this time we define a system for a particular application and do not place it into this directory.

Now we can use cl-launch to create and executable file that contains all the Lisp code that is necessary.

First we install cl-launch. In Gentoo Linux with lisp-overlay this can be achieve with the simple command at shell prompt:

emerge dev-lisp/cl-launch

In other Linux distributions you can use the ASDF-INSTALL to install cl-launch into system-wide or used directory:

(require :asdf-install)
(asdf-install:install :cl-launch)

Next we should create a Lisp image (a “core” file) that contains the cl-gtk2-gtk system and newly created hello-world application. If we will not create the image, the all code will be loaded from source files or from FASLs. Neither is fast. For example, loading cl-gtk2-gtk from FASLs takes as much as 30 seconds on my machine. During development, this is neglibible as it is loaded only once at startup.

Enter the following command to create the Lisp image:

cl-launch.sh -s hello-world -d hello-world-image

cl-launch loads the hello-world system (from hello-world.asd file from current directory) and saves the image as the ‘hello-world-image’ file.

If several Lisp implementations are installed, you can choose which of them is used:

cl-launch.sh --lisp sbcl -s hello-world -d hello-world-image

(But at the moment, cl-gtk2-gtk supports image dumping only with SBCL)

Next we use cl-launch to create a shell script that starts the program from a newly created image:

cl-launch.sh -m hello-world-image -i '(hello-world:run)' -o hello-world

Now, we should have a ‘hello-world’ shell script created.

Let’s run it:

./hello-world

In an instant, a window appears.

The application startup time is acceptable.

Now the only things that are needed to redistribute the application are hello-world-image file and hello-world shell script (and Gtk+ libraries, of course).

But the image size is quite big. On my machine, the image produced by 64-bit Linux version of SBCL takes 64 megabytes. Of it, SBCL takes about 42 megabytes, and the rest is cl-gtk2. SBCL is a native code generating compiler, so it produces large images. Byte-code compilers (like clisp) should have smaller sizes.

If this size is too much, there is an option of using gzexe program to compress the image.

gzexe hello-world-image

On my machine, this decreases the image size produced by SBCL from 64 megabytes to 12 megabytes and somewhat increases the startup time (but it is still quite fast).

It seems that one possible way of redistributing Lisp applications is to compile them from sources on target machine.