Re: New 'GObject' as base for GtkObject?

[David Benson <daveb idealab com>]

Yes, yes!!!! Thank you!  This would be exactly what I need,
and though I haven't spent too long considering the details
it looks great!

At first I was concerned I'd provoked an argument,
but this may truly be an excellent outcome.


Very pleased,
Dave


On Fri, 10 Dec 1999, Tim Janik wrote:

> 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
> 
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.
> 
>