Re: KDE Interop [Was: D-BUS background]
- From: Owen Taylor <otaylor redhat com>
- To: Zack Rusin <zackrat speakeasy net>
- Cc: Christian Fredrik Kalager Schaller <Uraeus linuxrising org>, Rodrigo Moya <rodrigo gnome-db org>, desktop-devel-list gnome org
- Subject: Re: KDE Interop [Was: D-BUS background]
- Date: 04 Mar 2003 22:16:16 -0500
> > 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
So, hopefully objections to GObject are along the lines of:
- It's too big (though it's decidely smaller than the rest of GLib)
- There's too much per-GObject overhead (whether this is true
is very much use case dependent.)
Rather than "I'd rather have plain C structures" ... GObject-based
libraries should almost always be easier to wrap in nice C++ than
"plain C"; there's no requirement for an automatic wrapping of the
signal system like gtkmm, even if the object has signals. If you
were willing to write hand glue for every function pointer callback,
you can write it for every signal as easily.
(Unless the library designers force you to implement your own types
to use the library or something... but that would be dubious design
for uses from C as well.)
Just thought that was worth pointing out ... I don't the detailed
considerations of the KDE team in this area.
] [Thread Prev