Re: KDE Interop [Was: D-BUS background] - re-using glib

I think it would be very useful to have a common underlying layer under
X11/MIT and implement GLib on top of that. The underlying layer should
be just data structures and memory allocation (+ byte ordering, etc.).
All the GObject, GModule and other stuff can go into GLib.

The first layer can be desk-top independent (no 'K'/'G' in the name ;-).
Another advantage: I'm sure many more commercial C apps would be using
the smaller core API if such a thing happens.

The main problem IMO will be deciding what goes to the lower layer and
what does to GLib.


On Wed, 2003-03-05 at 15:23, desktop-devel-list-admin gnome org wrote:
> Hi Owen,
> On Wed, 2003-03-05 at 03:16, Owen Taylor wrote:
> > > > I am just tired of hearing glib brought up as a problem everytime
> > > > code sharing is discussed because at this point that should be a
> > > > non-issue.
> > >
> > > GLib in itself is never an issue we can deal with core glib just fine,
> I
> > > just don't want any gobject's in core libraries and I think that's a
> > > reasonable expectation.
> >
> > It should be pointed out here that one of libgobject's primary goals
> > is to provide standardized memory management (and so forth) so that
> > GObject's can be wrapped in other languages or bridged to other
> > object systems.
>  There are several points that are interesting here; People have already
> split bits out of glib (libole2 eg.) for use in KDE, and (clearly) a
> common main-loop is a desirable goal with Qt.
>  It also somewhat worries me that people are adding yet more linked list
> routines to the stack;
>  Would it not make sense to create a 'K'lib - which re-implemented some
> of the common code, G(S)List, GHashTable, GMain*, GString etc. under an
> X11 license - either using the same symbol names and namespace, 'g_' -
> or simply wrapping / symbol aliasing them inside glib?
>  Then we could have the satisfaction of sharing code / maintenance, not
> having GObject/GType forced on us[1], and perhaps make things more
> efficient.
>  Probably an orthogonal, and/or distracting issue to D/BUS'
> implementation itself; but an interesting / possible one ?
>  Regards,
>   Michael.
> [1] - since apparently this is an emotive topic.
> --
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]