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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list