GtkPageSetupUnixDialog and GtkPrintUnixDialog objects added with their properties.
[cl-gtk2.git] / doc / doc.xml
1 <?xml version="1.0" encoding="utf-8"?>
2 <book>
3   <bookinfo>
4     <title>CL-GTK2 - a Gtk+ binding for Common Lisp</title>
5     <author>
6       <personname>
7         <firstname>Dmitry</firstname>
8         <surname>Kalyanov</surname>
9       </personname>
10     </author>
11   </bookinfo>
12   <chapter>
13     <title>TODO</title>
14     <para>Installation and requirements</para>
15     <para>*Introduction</para>
16     <para>Goals</para>
17     <para>Development History</para>
18     <para>Features</para>
19     <para>*Examples</para>
20     <para>*GObject binding: using objects, handling memory</para>
21     <para>*Using Gtk+ in Lisp: Gtk+, Widgets, main loop, threading</para>
22     <para>*Advanced GObject: defining objects, creating custom gobject classes, overriding and implementing methods and properties</para>
23     <para>*Internals: how gobject binding is implemented</para>
24   </chapter>
25   <chapter>
26     <title>Introduction</title>
27     <para>CL-GTK2 package is a Common Lisp binding for Gtk+ and related libraries. This package enables Lisp developers to develop Gtk+-based GUI applications.</para>
28   </chapter>
29   <chapter>
30     <title>Goals</title>
31     <para>The goal of CL-GTK2 is to provide portable (modulo threading, metaobject protocol, FFI), extensible and feature-complete binding for Gtk+ and set of related libraries (GLib, GObject, Gdk, Pango, Cairo, GdkPixbuf, GtkSourceView, etc.)</para>
32     <para>Gtk+ is writtent in C and uses object-oriented style of programming with support of GObject library. GObject provides classes, objects, memory management via reference counters, classes introspection, signals, properties. Goal includes "lispy" interface to GObject-based libraries. This means that GObject classes should map into CLOS classes, GObject instance into CLOS instances, properties should match to slots, it should be possible to attach closures as signal handlers. It should be possible to define GObject classes, implement properties, methods, signals, interfaces from lisp.</para>
33     <para>All memory management (object instances, closures, signal handlers, etc.) should be automatic. When applicable, optional support for manual management (using refcounts) should be provided for perfomance reasons.</para>
34     <para>All Gtk+ classes should be mapped, and the rest of the API should be mapped in lispy way. Support for NIH features should not be provided (e.g., do not expose GSList, GList, GHashtable, GUri but rather transparently convert to/from them).</para>
35     <para>Error handling should be provided; GObject/Gtk warnings and errors should be exposed as conditions. It should not be possible to bring Gtk+ into incostistent state when error in lisp code called from Gtk occurs (e.g., error in signal handler should not cause fatal errors but rather should be handleable).</para>
36     <para>CL-GTK2 should be threadsafe: it should be possible to make actions under the Gdk lock, and make actions from withing the GUI thread.</para>
37     <para>Ease of extending and updating to reflect progress of Gtk+ is also important.</para>
38     <para>CL-GTK2 should run main-loop threadedly; it should be possible to interactively modify the code while the GUI program is running.</para>
39   </chapter>
40   <chapter>
41     <title>Development history</title>
42     <para>This project was started by Kalyanov Dmitry in 2008. It was a hobby project to address the (perceived or real) lack of good portable GUI libraries for Common Lisp and to be able to use it for writing diploma (or is it called "graduate"?) project during final course of the university.</para>
43     <para>Initial intent was to use SWIG<footnote><para><ulink url="http://www.swig.org/">Simplified Wrapper and Interface Generator</ulink>; a program that automatically parses C and C++ header files and generates the binding code for many languages, including Common Lisp (targetting CFFI).</para></footnote> in order to be able to generate all of the code. After some experimenting, it was found out that use of SWIG would not help to achieve the goals. First of all, in order to create "lispy" bindings, a lot of integration should be done: object systems, memory management, passing closure and values, type mapping (G(S)List to list, GCallback/GCLosure to functions, etc.). SWIG is not of much help here.</para>
44     <para>So, it was decided to use CFFI and manually map all of the API. First, base infrastructure was created (definition of basic types, maps for basic types, integration with GObject object system and memory management, introspection of GObject types). Then large chunks of API were mapped with automatic generation of classes definitions. Then missing properties were added and functions were mapped.</para>
45     <para>In order to map GtkTreeModel, preliminary support for subclassing and implementing GObjects was introduced. With its help, lispy ArrayListStore (analog for GtkListStore) was implemented.</para>
46     <para>At the moment, next version of GObject binding using the CLOS MOP is being developed. It pretty much obsoletes class generation macroses and is neede in order to be able to make lispy maps of GObject methods into CLOS generic functions and to subclass GObject classes.</para>
47     <para>For future development, using GObjectIntrospection seems the definite way.</para>
48   </chapter>
49   <chapter>
50     <title>Features</title>
51     <para>Short summary of features provided by CL-GTK2:</para>
52     <itemizedlist>
53       <listitem><para>Mapping from GObject to CLOS with (partial) support for creating subclasses, overriding methods</para></listitem>
54       <listitem><para>Automatic memory management (with optional support for manual reference counting)</para></listitem>
55       <listitem><para>Lispy interface to related libraries (currently only to GLib, GObject, Gdk, Gtk)</para></listitem>
56       <listitem><para>Lispy mapping of Gtk+ API</para></listitem>
57       <listitem><para>Custom ListStore (TreeStore to be done) for GtkTreeModel</para></listitem>
58       <listitem><para>Partial error management (closures are invoked with restarts making it possible to cancel signal handling without crashing Gtk+)</para></listitem>
59       <listitem><para>Some high-level features based on Gtk+ API: with-progress-bar, with-message-error-handler</para></listitem>
60     </itemizedlist>
61   </chapter>
62   <chapter>
63     <title>GObject binding</title>
64     <para>At the base of Gtk+ is the GObject library. This library provides basic object-oriented system and various services. </para>
65   </chapter>
66 </book>