Re: Merging gio into glib
- From: Rob Taylor <rob taylor codethink co uk>
- To: Alp Toker <alp atoker com>
- Cc: Behdad Esfahbod <behdad behdad org>, gtk-devel-list <gtk-devel-list gnome org>, Havoc Pennington <hp redhat com>, Alexander Larsson <alexl redhat com>
- Subject: Re: Merging gio into glib
- Date: Wed, 14 Nov 2007 12:33:28 +0000
Alp Toker wrote:
> Alexander Larsson wrote:
>> On Wed, 2007-11-07 at 16:18 -0500, Behdad Esfahbod wrote:
>>> On Wed, 2007-11-07 at 16:07 -0500, Alexander Larsson wrote:
>>>> glib would need dbus as a build requirement for this to work (needs the
>>>> dbus types), and the glib header for the function would have to be
>>>> separate (with a separate .pc file for it) so that it can include
>>>> dbus.h, but it would work, and avoid an extra library. And if you squint
>>>> and ignore the implementation details it would be quite easy to use.
>>>> Just link to glib and dbus, then call the function.
>>> Assuming the scheme I wrote about in my other mail, this is nothing
>>> different. Yet another glib module. Lets call it gdbus. By default,
>>> glib build will put it in a separate .so, same for gthread, probably
>>> gmodule, and any other glib "module" that has external dependencies.
>>> But there will be configure options to build them all in one .so, or
>>> build them all separately, or add/remove on a one-by-one basis. What's
>>> the problem afterall to have libglib.so depend on dbus on fedora? It's
>>> the distributor dealing with the headache. It's transparent to
>>> applications.
>> It will mean that applications linking to libglib will suddenly pull in
>> more dependencies however. Thats not something that really happens with
>> e.g. gobject, and for gmodule the extra library is from glibc.
>>
>> For instance, isn't glib used on the Fedora initrd these days? That
>> would mean we'd have to add dbus to the initrd too.
>
> Alex, this topic seems to become popular again every few weeks, and will
> probably keep doing so until work is started on some kind of real
> libgdesktop module.
>
<snip>
>
> (PS. It was suggested that the GNOMEy features proposed for GTK+ could
> be made a configure option. Indeed, there is precedent for conditionally
> compiled platform-specific API like gdkx, which provides a handful of
> entry points to access the underlying windowing system. I don't think
> that making large chunks of high level API a configure switch is a
> sensible direction for a portable toolkit.)
I think the point is that those high-level api's would be implemented in
the appropriate way for win32/macosx, etc. It is not a plan to expose
dbus as part of these high-level apis.
As I understand it, these APIs would be akin to GtkPrintOperation.
Thanks,
Rob
--
Rob Taylor, Codethink Ltd. - http://codethink.co.uk
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]