[cl-gtk2-devel] Subclassing GtkWidget

[Maciej Katafiasz]

On Fri, Apr 16, 2010 at 00:39, Olof-Joachim Frahm <Olof.Frahm at web.de> wrote:
> Hi, the title says it: I'm having problems trying to understand how to
> create a subclass of a widget.  In C the corresponding code would set
> the class methods like
>> widget_class->realize = ...
> etc. and in python one'd implement the corresponding methods, so what do
> I have to implement to achieve this?
>
> Looking through the source code and following the todo list on the
> project page I'm currently assuming that the necessary definitions are
> not yet complete (?) and although for example I've successfully adapted
> the native GtkTreeModel implementation for my own data model, I'm a bit
> at loss how to proceed here.
>
> So what would help me are some directions either what macros/definitions
> to use, or what parts need to be implemented to get native widgets, so I
> could contribute there.

Indeed, that area is not yet complete. I've implemented parts of
what's needed[1], though that's also very incomplete and is currently
pending a refactoring to use proper meta-mechanisms such as custom GF
implementations and method combinations. With the naive approach of
throwing macros at it I took initially, you run very quickly into a
horrible mess when trying to call C methods on custom objects from
Lisp and vice-versa.

The problems arise at the boundary between C and Lisp parts of the
object's implementation, and are partially caused by the lack of
strict rules by which C GObjects are allowed to play, making it tricky
to implement the necessary Lisp-side glue. A proper support for
gobject-introspection is necessary to make things truly good, but even
then there are some unsolved issues when implementing GObjects in
Lisp, such as the fact that the calling context is lost when the
execution dives into the C side, making it possible and likely that
infinite calling loops could be created when trying to resolve the
proper calling order for methods. Another is that some code, like
GooCanvas, does unorthodox things along the lines of deciding which
method to call based on whether the appropriate vtable slot is NULL in
the class structure, making it impossible to implement Lisp stubs
properly. It will need some heavy thinking before it's anywhere near
being generically usable. But for now, feel free to take a look at my
code. Generating Lisp stubs works pretty well, calling arbitrary
GObject methods doesn't. CALL-NEXT-GMETHOD is where the mess I
mentioned lives. If you have any questions, feel free to ask. I'm not
actively working on it right now, but I'll be happy to help and do
intend to revisit it eventually.

[1]http://github.com/mathrick/cl-gtk2