Re: New 'GObject' as base for GtkObject?

[Tim Janik <timj gtk org>]

On Tue, 7 Dec 1999, Erik Walthinsen wrote:

> I've been working on a package recently (GStreamer) that uses the
> GtkObject system extensively.  However, that currently ties GStreamer to
> X, which isn't an option in the long run, since the objects I create have
> nothing themselves to do with graphical interfaces.

what exactly are you using from GtkObject?
it's major advantages are:
- reference counting
- generic data lists
- per object overloadable class functions
- the argument system
- the signaling system, often used for pure notification
- class functions that get executed during signal emissions
- derivation of types (i.e. the type system features)

reference counting, data lists and function tables can esily be
implemented for any kind of structure (a glib data list abstraction
is already there).
the argument system and the type system are pretty closely tied to
gtk's needs and due to that come with their own kind of specializations/
drawbacks that make them less usable for a generic object system.

the signal system though is a very convenient and flexible mechanism to
perform various kinds of notification and to implement customizable object
methods. it is certainly tempting to have a general purpose abstraction
for that. unfortunately it is pretty closely bound to gtk's type system
and base object. it also comes with certain hurdles for language bindings
that want to introduce own signals.

> What I'd like to propose is that the base GtkObject system as it stands
> now be moved into glib and set up as a generic object hierarchy, upon
> which GtkObject and other object hierarchies can build.  This system can
> then be extended with some of the things I'm needing, such as locking,
> either by subclassing or in primary implementation.  It would provide a
> general-purpose C object system that can be used without depending on
> anything else (like X, or win32 I suppose), and make it a lot easier for
> someone trying to build a hierarchy to figure out what on earth needs to
> be done (I may write up a tutorial on that someday).

when i was about to implement BSE (bedevilled sound engine) which amongst
other things had to support synthesis networks of objects and normal
container<->child relationships, my first approach was to reuse the gtk
object system for that as well.
but then i got struck by some of its most prominent shortcomings:
- classes are not reference counted and therefore are not destructable
  either, which makes true plugins that want to introduce new types
  completely impossible
- gtk arguments are a pretty poor abstraction of per-object properties, they
  just provide very primitive type information like int, pointer, float and
  it is impossible to monitor object state changes because an object
  property changes are not routed through the argument system exclusively.
  (one of the GnomeCanvas' biggest problems is the lack of notification
  upon argument changes, so it's for instance hard to keep track of the
  movement of a GnomeCanvasItem, eventhough it does route all item changes
  throguh the argument system).
- the possibility to imperatively destroy objects overcomplicates various
  kinds of object implementations, because in principle you'd have to
  double check your object's state upon every function entry and after
  every function call that *might* cause third party code invocations
  (such as signal emissions or modifications of object data).
- support for constructor arguments is pretty limited and tedious for
  object implementators (and imposes some shortcomings that have yet
  to be solved comprehensively).

the gtk+ object, type and signal systems are pretty impressive upon first
observation, especially because one can make it as fast/flexible as desired,
since in C you can (actually *must* <shrug> ;) control every single detail
of its implementation.
but it is often not realized that certain things are
implemented a certain way, not because it was the best/obvious way to so
(for the purpose of a generic object system implementation), but to maintain
source compatibility for gtk programs over the years or simply because
they fit gtk's purposes while they would fall short for other applications.
in the end we wrote/maintained a type and object system that would fit
a toolkits purpose, not a dynamic type system's reference implementation
in C ;)

so i finally ended up writing my own type system for BSE which has lots of
analogy to gtk's but features truely dynamic type implementations and has
it's own parameter interface that is severly improved compared to gtk's
(lots of code has been traded in that respect between both projects).
it also routes all object modifications through central points which
allow for an extremely easy way to implement undo/redo facilities,
greatly aid object serialization, and of course provide sufficient
object state change notification.
of course i also constrained that new type/object system in some ways so
it'd better suit BSE's purposes, for instance i didn't need all of gtk's
signal system's flexibility and simply implemented notification based on
GHookList.


> This, I think, would also help another issue I'm struggling with right
> now: "easily" creating Perl bindings for the objects.  From the gnome-perl
> package it seems as if there is object-system support code scattered all
> over the place, making it extremely difficult to figure out how on earth
> to create a standalone Perl binding for an object hierarchy such as mine.
> With appropriate tools, i.e. a modified form of SWIG, creating bindings
> could be truly a piece of cake.
> 
> If this is deemed a useful thing (which I hope it is), I'll be glad to
> help bring it about, as it would make my life a lot easier.  I think I
> understand enough of the GtkObject code to be able to do the initial work
> of stripping it out of Gtk and making it generic.

after more than two years of experience with two distinct C based type
systems (and another proxy-object system implementation retrofitted on
top of gtk's type system for GLE, which had to go through some lengths
to bow gtk's type system to at least make it virtually pluggable for
new fundamanetal types) i'm deeply convinced that gtk's current
implementation is not what we want to see various types of 3rd party
C based OO implementations be based upon.
rather a more generic system needs to be designed from scratch which takes
into account the experience made with gtk+, the needs for serialization
and notification like they arrive in e.g. raph levien's gdome implementation,
language binding interactions (with full support for derivation/implementation
of new types on the binding side) and probably some generic querying/handling
issues like they arrive for GUI builders or other entities that need to handle
different object types without any special knowledge implementations.

this may sound overly complex and undoable, but the reuqired knowledge is
already there in the minds of language binding, gdome, gtk+, libsigc++ etc...
project maintainers. it's just ;) a matter of this bunch of people getting
their guts together and come up with a profound design.

> 
> TTYL,
>     Omega
> 

---
ciaoTJ