Re: KDE Interop [Was: D-BUS background] - re-using glib
- From: Biswapesh Chattopadhyay <biswapesh_chatterjee tcscal co in>
- To: GNOME Desktop <desktop-devel-list gnome org>
- Subject: Re: KDE Interop [Was: D-BUS background] - re-using glib
- Date: 05 Mar 2003 15:42:49 +0530
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
>
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]