Federico Mena Quintero wrote:
>
> I think you and Havoc agree on everything, *except* for "what stuff can
> GTK+ depend on?".
>
Part of it is that I think there are degrees of dependency. Here are
some cases:
- Hard cross-platform API dependency - the dependency is in the GTK
headers on all platforms.
e.g. Cairo, Pango.
- Hard single-platform API dependency - e.g. Xlib, due to gdk/gdkx.h
- Soft library dependency (cross-platform or single-platform) -
the dependency is not in pkg-config --libs gtk+-2.0,
but GTK links to it. Dependency could in theory be removed.
e.g. libpng.
- Soft library dependency with side effects - e.g. D-Bus might
be like this. This happens if the use of a library isn't
"invisible" to the app, I'm not sure if D-Bus would be, though
it potentially could be if handled carefully.
If there are side effects of using a lib, then potentially
those side effects become part of the ABI.
- Runtime dependency - GTK dynamically dlopen()'s the lib
if present. No current examples AFAIK.
- Module dependency - the dependency is in a GTK+ module,
which gnome-session or something arranges to load.
- File or protocol dependency - GTK+ looks for and parses some
file it expects some other app/desktop-component to write,
or talks to some component via a protocol like XSETTINGS.
- Out-of-process dependency - have a helper process that e.g.
connects to D-Bus or the session manager and talks to
GTK via pipes; this is a way to use another library/service without
bringing it into the application's address space.
Using these creatively is one way to get stuff into GTK+ and keep app
developers from having to write their own #ifdef GNOME hell.
For example, if there were a library that just installed all the gtk
"hooks" for help and so forth, I'd expect that library to have one function:
void gnome_install_gtk_hooks(void);
This is an obvious candidate for being a gtk module that GNOME arranges
to load into all GTK apps, since it has no actual API, it just needs to
be loaded and initialized.
Take the D-Bus example - I see no reason GTK needs D-Bus in its headers
in the way it has Cairo in them. It would just be pointless cruft.
So if you proposed that in bugzilla, I can imagine the GTK maintainers
saying "we don't want a D-Bus dependency."
But, if GTK had a "GdkSession" interface or something, I don't see how
it's rocket science to implement it. I mentioned a number of ways to do
it in my big list o' kinds of dependency just now.
The basic path forward I'd suggest is to use some of the softer kinds of
dependency I mentioned to take advantage of gnome-vfs/gconf as required,
and consider introducing harder dependencies on vfs/configuration libs
if someone creates less hosed vfs/configuration libs.
Right now lots of app authors are hand-rolling the soft dependency
flavors anyway, the #ifdef GNOME syndrome. But nobody wants to have to
do this.
Havoc
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
