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

[Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>]

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.

Rgds,
Biswa.

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
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
>