Re: CVS reorg

[Owen Taylor <otaylor redhat com>]

Martin Baulig <martin home-of-linux org> writes:

> Owen Taylor <otaylor redhat com> writes:
> 
> > Tim Janik <timj gtk org> writes:
> > 
> > > can one of you in the CVS repo please do the following:
> > > 
> > > copy glib/gobject/gbsearcharray.[hc] to glib/gbsearcharray.[hc] 
> > > copy glib/gobject recursively to glib/gruntime
> > > copy glib/gmain.[hc] to glib/gruntime/glib/gmain.[hc]
> > > 
> > > i'll handle include files/build setup stuff after that.
> > 
> > Before we go ahead and do this, let me ask once more, do
> > we really want to go with the s/gobject/gruntime/ change?
> 
> Eeeek, NOOOOOOOOOOOO !
> 
> Why the hell do you guys want to rename GObject to something else ?

No, we are talking about the library.
 
> >  - We'll confuse people; think how long people kept on
> >    talking about GTK+-1.4. People recognize gobject
> >    and know what it is at this point.
> > 
> >  - gruntime is an ugly name.
> 
> So can someone please enlighten me here, do you just want to rename the
> directory/library `gobject' to something else or do you also want to
> rename the GObject type and the g_object_* () function names ?

The library/directory is the thing in question.
 
> >  - Once we start moving stuff into gruntime like the main
> >    loop, its not really clear where the boundary is,
> >    and possibly a separate library for gobject just
> >    doesn't make sense.
> > 
> >    What's is the precise definition of what belongs in
> >    one library and what belongs in the other?
> 
> Guys, please don't start doing the same kind of "mess" we had in GTK+ 1.x
> where there was no clear boundary between the object model and the widget
> set.
> 
> We're currently in a situation where GObject as an object system may become
> useful for non-GNOME and even non-Gtk projects; and IMHO this will loose a
> lot of its value if we move stuff like the main loop into gobject.

You have it backwards here. There is discussion of moving the main
loop implementation into gobject not so that the object system can
depend on the main loop (it already could, if that was a good idea),
but rather so that the main loop can use GObject system features - in
particular GClosure.

Regards,
                                        Owen