Re: libgnome deps



Richard Hughes wrote:
On Tue, 2007-07-03 at 12:18 +0200, Jani Monoses wrote:
the benefits besides having somewhat lighter apps is that some of the
GNOME modules would more likely be
adopted by other projects - in particular Xfce - instead of them doing
something from scratch or maintaining existing
similar projects using the valid excuse that there are too many
dependencies in the GNOME ones.

The only things that's stopping me applying the patches for g-p-m are:

* We duplicate a lot of logic for just opening a help file, I'm not
happy about all the copy and paste code in every module just to open a
help file. Maybe we can get this split off into another (tiny) helper
library?

I agree copy-pasting sucks. But in this case even if the helper library is tiny it
will likely cause more copy pasting and complexity (add autoconf props, new dependencies
for packagers, a longish process until it's agreed upon what the lib should contain and
API stability concerns..). IMHO we should have less libs and byte the bullet and deal with
one copy pasted function once in a while until it gets into existing platform libraries.
OTOH if it's an egglike library, you have copy paste as well...


* Getting rid of gnome_program_init removes bug-buddy integration. This
is a killer from my point of view. Can we _easily_ use bugbuddy without
gnome_program_init?

I agree with this as well. While there are modules that do not gain much from bug buddy, some
often get valuable reports from it. Originally I though bug-buddy as external lib effort is in the 2.20
timeline but it does not appear to be so, probably because that project is more ambitious than just
moving out bug buddy from libgnome.

Anyway another option until that is fixed is having --enable-gnome as a config option. Quite a few
GNOME modules have that so they can optionally run in non-GNOME desktops be it Windows, Xfce or low memory
devices.

This is probably up to the maintainer to consider, but in most cases it is one #ifdef choosing between gnome_program_init
and gtk_init, so definitely not a maintenance problem after the initial routine patch is applied.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]