Re: gnome desktop integration library

[JP Rosevear <jpr novell com>]

On Wed, 2006-09-06 at 10:11 -0400, Tristan Van Berkom wrote:
> Havoc Pennington wrote:
> [...]
> > But as an app developer, how do I decide whether I want to do that? Do 
> > we need two versions of every app, one that "tightly integrates" and one 
> > that does not? Why can't the library figure this out for me?
> > 
> > As an app developer I'd say I clearly want to _both_ tightly integrate, 
> > _and_ be cross platform, _and_ have only solid, stable dependencies. I 
> > don't want to choose among these things.
> 
> I cant agree with you more, who needs this bussiness of littering thier
> codebase with "#ifdef HAVE_GNOME" just to provide a couple of extra add-on
> fringe features that supposedly "integrate well" - at the cost of having
> a dual build to maintain - ugh the pain.

#ifdef HAVE_GNOME is a choice the app developer has made, if they don't
want to rely on a complete desktop then they'll replace this #ifdef with
another if all the stuff is in gtk+, #ifdef
ENABLE_ONLINE_OFFLINE_SUPPORT, or something similar.

> I think that right now - people might feel the need to have a "libgnome"
> that has all that extra crap that people might need in some fringe case
> to integrate well with gnome, but realisticly that will never happen.

No, I feel no need to put crap in a library, I outlined several useful
cases in a previous mail that are not crap at all.  The issue is
historically this higher level stuff has simply not gone into gtk+.

> Why ? because as soon as something is adequately s
> table and usefull in
> that library - it will probably wind up in gtk+, leaving us eventually with
> the mostly depricated spaghetti we know today as libgnomeui.

gconf is adequately stable and useful, its not there (yes, Havoc posted
some problems, but realistically many, many apps use gconf and it works
reasonably well).

> I have the feeling that the proposed libgnome may solve some problems
> on the immediate front - but essentially in the long run we need:
>    - A general purpose UI toolkit / platform library that is GTK+
>    - Anything that "logicly" breaks the boundry in a seperate lib
>    - We are also sorely in need of a portable ipc for the desktop domain,
>      I'm sure the gconf & dbus people are working that out and I'm personally
>      unaquianted with any of thier specific issues - what is clear is that
>      ultimately this ipc should be accessible from GTK+, regardless of whether
>      or not it uses a hard dependancy.
>
> So in summery - my thoughts are that, given we dont have mountains of unlimited
> resources to go writing code spikes at leasure, we should completely ignore
> whatever short term gains can be achieved by creating more of a mess, and we
> should look to the future - find out what functionality belongs in gtk+ and
> what functionality belongs in its own seperate lib and eventually do our homework
> and hammer it all into place, while this could take years to achive - so could
> the writeup of yet another bundle of special-case libgnome... what would you
> prefer to have 2 or 3 years down the road ?

First, the original proposal was to combine two *existing* code bases
with a little cleanup.  Second, we are not talking code spikes here
because its only a question of location in a library, not implementing
something twice.

-JP
-- 
JP Rosevear <jpr novell com>
Novell, Inc.