cl-cffi-gtk is a Lisp binding to GTK+ 3 which is a library for creating graphical user interfaces.cl-cffi-gtk is licensed using the LGPL which has been adopted with a preamble
that clarifies the terms for use with Lisp programs and is referred as the
This work is based on the cl-gtk2 library which has been developed by
Kalyanov Dmitry and already is a fairly complete Lisp binding to GTK+ 2.The focus of this work is to document the library more complete and to
do the implementation as consistent and complete as possible. Most informations about GTK+
can be gained by reading the C documentation. Therefore, the C documentation
from The GTK+ Project is included into the Lisp files to document the Lisp
binding to the GTK+ library. This documentation is also available online at
cl-cffi-gtk API documentation.At this time, the library is developed and tested with SBCL 1.1.9 and
GTK+ 3.6.4 on a Linux system. Furthermore, the following libraries GLIB 2.36.0,
Pango 1.32.5, and Cairo 1.12.4 are loaded.Examples of the usage are included in a gtk-demo and tutorial examples. Start
with the tutorial available online at
GTK+ 3 Tutorial for Lisp
to learn how to use the library. Some more information and a gallery are available from the project website
cl-cffi-gtk Project.The latest version is available from the repository at
Minimal bridge to Tcl/Tk
Mozilla XUL bindings for Common LispHomepage
Source repositoryLicense: BSD
Embed Tcl/Tk scripts in Common Lisp
Pure Common Lisp library for antialiased cursor rendering for clx.
clx-truetype is pure common lisp solution for antialiased TrueType font rendering using CLX and XRender extension.
CommonQt is a SMOKE-based binding to the Qt GUI library.Homepage: http://common-lisp.net/project/commonqt/License: MITSee also: qtools cl-smoke eql
Common Lisp bindings for the ncurses terminal library.
Halftone is a simple image viewer written with Qtools. The project can be found on github.
As of 2015, halftone is on Quicklisp.Halftone is licensed under the Artistic License 2.0.
McCLIM is an implementation of the CLIM 2.0 specification.
Working with CommonQt/Qtools currently requires working with SmokeQt. However, SmokeQt is not easily available on all platforms (especially OS X and Windows). This project should simply ensure that the libraries are either available by your system directly, or that they are built automatically for you. This ensures that CommonQt can be used directly with hopefully no further user intervention being necessary.The project can be found on github including a fully documented symbol index and a getting started tutorial.
As of 2015, Qt-libs is on Quicklisp.Qt-libs is licensed under the Artistic License 2.0.
Qtools aims to be a toolkit to support development with CommonQt. This goes to the point of sporting a complete abstraction layer that makes writing Qt applications look like regular Lisp programs. Have a look at the documentation and examples to get an idea.The project can be found on github including a fully documented symbol index and a getting started tutorial.
As of November 2014, Qtools is on Quicklisp.Qtools is licensed under the Artistic License 2.0.
This is a collection of useful widgets and pre-made components for use in your Qt applications. There is no specific scope that limits what might fit into this library, but for the most part it concerns itself with things like layouting and other base components that can be used anywhere.The project can be found on github including a fully documented symbol index.
As of November 2015, Qtools-UI is on Quicklisp.Qtools-UI is licensed under the Artistic License 2.0.
Extensions for ASDF.
CFFI bindings for curses.
CL-GTK2 is a Common Lisp GUI library that provides access to the Gtk+ cross-platform GUI library in idiomatic Lisp style.CL-GTK2 should portably work in most modern Lisps that support CFFI and MOP (works at least in SBCL, Clozure CL on Linux and Windows). Current version is 0.1.1 released on 2009.12.30.cl-gtk2 blog contains news on development of CL-GTK2. There is also a common-lisp.net website, with more documentation.CL-GTK2 is ASDF-installable (install the :CL-GTK2-GTK, :CL-GTK2-CAIRO and :CL-GTK2-GTKGLEXT systems).Requirements:
FFI with callbacks (via CFFI)
Threading (via Bordeaux-Threads)
Weak references (weak hash-tables) and finalizers (via Trivial-Garbage)
CLOS Metaobject Protocol (via Closer-MOP)
Provides Gtk+ API in a Lispy way
(Almost) Complete Gtk+ API
Objects and classes are mapped into CLOS objects and classes
Gtk+ objects are garbage collected
Error in objects' signal handlers are restartable
Provides some higher-level abstractions over Gtk+ facilities:
Calling code in GUI thread (call-within-main-loop, call-within-main-loop-and-wait)
Displaying progress-bar for long-running code (with-progress-bar)
Displaying errors (with-gtk-message-error-handler)
(defun run ()
(let ((output *standard-output*))
(let ((window (make-instance 'gtk:gtk-window
:title "Hello world!"
(button (make-instance 'gtk:button :label "Hello, world!"))
(gobject:g-signal-connect button "clicked"
(declare (ignore b))
(format output "Hello, world!~%")
(setf (gtk:button-label button)
"Hello, world! (clicked ~D times)"
(gtk:container-add window button)
(gtk:widget-show window :all t)))))
(defun demo-class-browser ()
(let ((output *standard-output*))
(let* ((window (make-instance 'gtk:gtk-window
:title "Class Browser"
(search-entry (make-instance 'gtk:entry))
(search-button (make-instance 'gtk:button :label "Search"))
(scroll (make-instance 'gtk:scrolled-window
(slots-model (make-instance 'gtk:array-list-store))
(slots-list (make-instance 'gtk:tree-view :model slots-model)))
(let ((v-box (make-instance 'gtk:v-box))
(search-box (make-instance 'gtk:h-box)))
(gtk:container-add window v-box)
(gtk:box-pack-start v-box search-box :expand nil)
(gtk:box-pack-start search-box search-entry)
(gtk:box-pack-start search-box search-button :expand nil)
(gtk:box-pack-start v-box scroll)
(gtk:container-add scroll slots-list))
(gtk:store-add-column slots-model "gchararray"
(format nil "~S" (closer-mop:slot-definition-name slot))))
(let ((col (make-instance 'gtk:tree-view-column :title "Slot name"))
(cr (make-instance 'gtk:cell-renderer-text)))
(gtk:tree-view-column-pack-start col cr)
(gtk:tree-view-column-add-attribute col cr "text" 0)
(gtk:tree-view-append-column slots-list col))
(labels ((display-class-slots (class)
(format output "Displaying ~A~%" class)
repeat (gtk:store-items-count slots-model)
do (gtk:store-remove-item slots-model (gtk:store-item slots-model 0)))
for slot in (closer-mop:class-slots class)
do (gtk:store-add-item slots-model slot)))
(declare (ignore button))
(let* ((class-name (read-from-string (gtk:entry-text search-entry)))
(class (find-class class-name)))
(gobject:g-signal-connect search-button "clicked" #'on-search-clicked))
Gtk GTK binding
An implementation of the X Window System protocol in Lisp.
HTML-TEMPLATE is an HTML template library to use templates much like Perl's HTML::Template. Despite of its name, HTML-TEMPLATE is HTML-agnostic and could be used for templating other documents.It was written by Edi Weitz and can be found at http://weitz.de/html-template/.Jörg Höhle also liked the idea of a clear and complete
separation between HTML (written by designers) and code. He
came up with a variant of Edi's approach to HTML template. It uses
Edi's parsing code (thanks!), no more, but the programmer view on it
feels very different.Consider Edi's 7x7 chess board example on his documentation page and
how my code would look like:(setq my-template
;; load and check against specification
(tmpl-load "file.html" '((LOOP rows (LOOP cols colorful-style content)))))
(let ((counter 0))
(loop repeat 7 do
(loop repeat 7 do
(funcall cellprinter (oddp counter) (format nil "~R" counter))
Jörg Höhle's design goals:
Separate HTML design from code as much as possible, the key
idea in the template approach.
Verifiable specification of the interface between
both, never see "$foo" in a user's browser as an indication that
some variable was not substituted.
Designer and programmer work concurrently early
on. The programmer may use a default template automatically derived
from the specification, the web-designer a random-content template
delivering web-server based on this specification.
Efficiently deliver data, which should be no
slower than frameworks based on direct embedding of code in HTML or
vice-versa. That's why I rejected intermediate structures (Edi's template
structure) and produce compilable code. A parsed template
becomes Lisp code, which can be either compiled and loaded as such
from the file system, or compiled on the fly at load-time.
Incrementally deliver results as produced (useful
for huge data or HTTP 1.1 chunked encoding) which is incompatible
with non-lazy intermediate structures.
Provide for lexical scoping in templates,
unlike Perl's HTML::Template. That is, a TMPL_VAR occuring
inside TMPL_LOOP may refererence variables defined in an
outer (e.g. global) level. There's no need to repeat definitions at
Deliver data in pieces as large as posible: i.e. no individual
calls to PRINC or FORMAT for each HTML tag, coalesce these
Early HTML validation of the templates
some more I forgot...
[This next section confuses me a bit. I think a list entry refers to Edi's version, but I can't really tell.[
Some differences between Edi and Jörg's work include:
No facility for caching or automated reloading, which I feel
orthogonal to templates, interferes with
TMPL_INCLUDE and is left to the application.
An attempt to load templates validates them, so the running
web-server application will choose to reject template updates (and
log the error) until they are corrected instead of displaying
garbage to the user.
TMPL_VAR may have content, which is valuable for
the web designer's GUI: s/he sees this content up to a closing
Variable subtitution on the code side is based on ordering
in the specification, not on names or symbols, so there are no
surprises with packages and symbol-names across files.
The template substituting code is trivially small and was
ported to Scheme. In fact, there's almost no such code since it's
in part in the programmer calling sequence (witness the above
example) and part in the Lisp code representing the template.
Edi's got a package ready to go for you. [So is there code somewhere interested people could hack on, or something?]
The above specification is not all about the interface between
programmer and designer. URL structure, form names etc. need also
be agreed upon.
The template approach is very useable for
applications with small or medium demand for variable
appearance. Or you'd need too many templates.
I generated pages using templates featuring highly
dynamic content (e.g. variable numbers of both rows and
colums of a table, selectable and variable order) which some people
initially thought not usable with a strict templates approach. It
was, in fact, clean and easy.
TMPL_LOOP and TMPL_VAR are really
general and could even emulate TMPL_IF.
I generated my templates from Lisp code via SXML, instead of
having a designer. This aids consistency among templates. For a
all-by-one-person job, the separation is clear overhead, even if
there's potential for code reuse. You'd probably prefer a
HTML-from-sexpr approach in such a case and bypass templates.
HTML validation of the templates is hindered by
TMPL_IF with an ELSE part, substitutions
inside attributes and obviously only possible when the
substitutions done by TMPL_VAR affect the HTML
structure. The most dynamic template is TMPL_VAR
As an enhancement, there could be a mechanism for global
substitutions which would remain outside of the specification.
E.g. some pages like to display calendars, the current date or use
a mapping from month names to numbers etc. Such substitutions could
always be present, across all pages of the application.
Compatibility library to run things in the main thread.