Re: New 'GObject' as base for GtkObject?

[Tim Janik <timj gtk org>]

On 9 Dec 1999, Owen Taylor wrote:

> 
> Tim, 
> 
> I know you've taken a dislike ;-) to GtkObject now and are opposed
> to splitting it out of GTK+ for that reason, but I don't think this
> is a valid line of reasoning.

heh, it's not like GtkObject insulted me some rainy day and since then
we have a dislike for each other and want us to stay where we are ;)

it's mere that i'm worried about code quality.
federice pointed out an important thing in this thread (not for the
first time though), that is model/view abstraction. and with more and
more people wanting to have a solid fundament to implemnt component
based models, the desire for a good c based object sytem definitely
grows.
but while what we have in gtk mostly serves a toolkit programmer's
needs, it is simply not generic enough and too limited to serve as
that solid fundament.
so when we actually split GtkObject into a seperate library right
now and people start (or as far as miguel is concerned: continue)
to use it, we will all suffer ;) from big ugly hacks around its
inconveniences and shortcomings in one or two years (such as the
problems with constructor args, object change notification lack, or
the primitive property support of gtkarg have already cause grief
in the past).
that's what makes up my line of reasoning, and i consider it very
valid ;)

> 1) Yes, Gtkbject is meant as an object system for a widget toolkit, 
>    and I'd like to keep the useful bits of that specialization, but
>    people seem to be finding it useful for other projects _in that form_.

not definitely "in that form", probably everytime i've come across
(or raised ;) the topic of splitting up the GtkObject system, there
were always voices ala "why doesn't it feature foo" and "if it just
hadn't bar implemented in the baz way", even this thread is no
exception to that rule.

> 2) We cannot expect people to learn and use TWO C-based object
>    and type systems in the same applications. So people are
>    going to use GtkObject for "inappropriate purposes" whether
>    you like it or not.

yes, i certainly realize that. and while i've been maintaining gtk's
type/object and signal system for quite some time now, been coding
BSE and GLE, the very first steps of coding BEAST actually confused
me to some extend since i was dealing with three different types
of (pseudo-)object systems ;)
so i'm not really an advocate of using multiple object systems
in one appllication, eventhough that is what i currently have to
do in BEAST (i got rid of GLE as of recently at least ;).

> 3) The improvements that you have made to GtkObject fall into
>    various categories:
> 
>    a) Improvements that are possible in a backwards compatible
>       way. (E.g. interfaces, planned for GTK+ 1.4.)
> 
>    b) Improvments that are not possible in a backwards compatible
>       way but we need to make anyways to GTK+. (E.g., improvements
>       to the argument system)
> 
>    c) Improvments that would have been nice to put into GTK+
>       from the start but can't be done now without causing 
>       horrible breakage. (More sane refcounting, perhaps.)
> 
>    d) Improvements that might be desirable in general, but are
>       not desirable for GTK+. 
> 
>   I'm very unconvinced that once the a) and b) improvements are made,
>   that most people would care about the difference between GtkObject and
s/would/wouldn't/ i guess

>   your ideal system. After all, people seem to be reasonably happy using GtkObject
>   right now.

i'm not claiming to have the ideal system here, but i do consider
certain things fundamental for a generic component system -
a), b) and c) certainly being the key concepts.
i *am* sure that most people will agree with me on that point, once
they've actually experienced the facilities offered to them through
those options.

> So saying "forget GtkObject, use BseObject" carries no weight for
> me. It isn't a long-term viable solution. 
> 
> Maybe you aren't saying that - maybe you are just saying "GtkObject
> isn't ready yet". But if that is what you are saying then I'll
> challenge "if not now, when?"

nope, i'm not telling people to use the BseObject system, it has its
own kinds of specializations in some areas as the GtkObject system.
i did write David Benson to take a look at it, because of the great
amount of overlap with BSE that i suspected from the needs and the
purposes he outline about his project.

> What is your timeline for improving GtkObject to the point you would
> feel comfortable with people using it for non-GUI purposes? Is there a
> reason why this couldn't be done now, and the improvments made as part
> of the separate library?

well, you really got me thinking here, and in fact i spent the last 2
hours looking at gtk, bse and some of the language bindings.
what i think could be a reasonable path, is to seperate out the basic
type, object and signal system of gtk/bse and compose a new library
gobject.la, supposedly shipped with glib.
the gtk core mechanisms (as well as those of bse) will then be
implemented on top of that (thus BseObject and GtkObject will derive
from GObject). this will of course carry a little bit of gtk related
cruft over to gobject.la but i think that can be kept to a
reasonable minimum.

the outstanding features of that would be:
- the basic type system functionality with a small amount of
  fundamental types, probably
  G_TYPE_INVALID,
  G_TYPE_NONE,
  G_TYPE_PARAM,
  G_TYPE_INTERFACE,
  G_TYPE_ENUM,
  G_TYPE_FLAGS,
  G_TYPE_OBJECT,
  G_TYPE_SIGNAL,
  G_TYPE_FOREIGN,
  G_TYPE_GTK_ARG,
  G_TYPE_GTK_CALLBACK,
  (the last one may not even be necessary with proper support for
   3rd party fundamental types)
- support for enum and flag value lists
- support for a single-inheritance reference-counted object system
  (with proper class destruction)
- support for multiple interfaces per object type
- support for per-object quark data (the base GObject shouldn't
  take up more than 12 bytes, i.e. a class pointer, reference count
  and a GData* pointer)
- support for gtk-alike object signals
- basic support for a more flexible parameter system to get/set/monitor
  object properties
- hooks for type system change notification (type/class/object creation
  and destruction)
- hooks for type plugin implementations

i believe that the bse stuff could easily be ported over to that, and the
gtk system with reasonable amount while maintaining 95% source compatibility.
in fact, the three things i currently envision causing some headaches are
going through the language bindings, search for assumptions about
GTK_TYPE_OBJECT being the absolute base type and fixing up
GTK_FUNDAMENTAL_TYPE() and GTK_TYPE_SEQNO() related stuff.

later, we then have the options to either
- port the GtkArg system over to GParam with huge amounts
  of ugly glue code (obviously not my favourite ;)
- start using the GParam facilities besides GtkArg for a transisition time
  of one or two major release cycles and finally drop GtkArg

i'm not yet completely clear on the glue required to get the gtk_signal_*
interface going on top of g_signal_* which will be based on some core GParam
types (derived from G_TYPE_PARAM).

pros i see:
- we get a reasonably good C based type/object system implementation that
  can serve as a solid and flexible fundament to implement various application
  specific object systems on
- there will of course not exist any GUI or sound or what-else related
  dependancies to make use of the type/object system, and with that a
  wider variety of applications/libraries is actually able to make use
  of often needed feature such as enum stringification, reference counting
  and quarked data
- we get class destruction and therefore true plugin abilities for
  non-gtk objects (making gtk's object classes destructable would simply
  cause too much source incompatibility)
- we have a great potential here, to fix the remaining holes with regards
  to language bindings, assuming that language binders participate in
  the process of accomblishing this library

cons i'm so far aware of:
- well, while a rough 70-80% of the required code already exist, it is a huge
  amount of work required to get the library going in the first place, and
  of course to retrofit the existing gtk core code on that
- this will probably delay the estimated release schedule of the next major
  gtk release (though i'm not sure we have such a schedule already ;) by
  (rough guess) one to two months
- there's another library added to the ldd list (i don't consider this an
  issue, but i want to be ahead of the guy that would bring this up anyways ;)

i guess i could have a prototype of gobject.la in glib 1.3 by the end of
december, if we decide to go this route within the next week.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ