Re: Merging gio into glib

[Rob Taylor <rob taylor codethink co uk>]

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