Re: gnome desktop integration library

[Havoc Pennington <hp redhat com>]

JP Rosevear wrote:
> > But if you are talking about a *general purpose* desktop integration 
> > lib, then that's all stuff that gtk should have. There's no value at all 
> > to a separate stack of stuff, and there's tons of negative such as new 
> > developer confusion.
>
> I think that the developer confusion of a smorgasborg of small libraries
> can't be discounted either.

Library splittiness is sort of separate from this discussion I think; I 
mean, you can have glib + cairo + pango + gdk + gdk-pixbuf + gtk, or you 
could glom them all into one shared object, but the important thing is 
whether they "make sense" together as a whole (and ideally have one 
reference docs tree, tutorial, etc.)

> > I challenge anyone to make the case for why something of general 
> > interest to application authors should be in gnome only vs. "the 
> > gtk/freedesktop stack" - I can't think of a single example.
>
> The Open With editing dialog from nautilus is such an example I believe.
> Firefox would use it if in a common place, file roller should use it, so
> should evolution.

But why should this only be in "GNOME apps"? Is Firefox even a "GNOME 
app"? If you'd define Open With as useful to apps generally, why should 
it not be in gtk? If you'd define it as useful to some set of apps, is 
there some way to say "this library is for apps that ____" and put "Open 
With" in that well-defined library?

The core is that I don't see how "gnome stuff" is a library definition.
If it means "important stuff to integrate with the application's 
environment" that clearly falls under gtk's definition also.

A lib called "libsetup-gtk-hooks-to-use-gconf-and-vfs" is a lot better 
than a "libgnome" because it has a definition. A lib like 
"libnotcrossplatform-x-desktop-specific-apis" is also a lot better than 
libgnome - it would tell app authors exactly whether they should or 
should not use it (and how, e.g. maybe app authors want to only 
conditionally use that lib).

> Lockdown is another example, if every app that launched a viewer/editor
> (nautilus, evo, file-roller, mozilla, gftp, nautilus-sendto) used a
> central API call to launch other applications, its easy to have
> white/blacklists.  Anything that could be defined as policy would be in
> this library.  Maybe this stuff could go into gtk+, but not until gtk
> can depend on gconf, for which there has been reluctance in the past.

A libwidgets-preconfigured-to-use-gconf-lockdown is a good lib 
definition (didn't George write this already?), even though it might be 
nicer to put that feature in gtk (this lib seems inherently 
"GnomeLabel"-inducing since you'd need a new version of every widget).

> Online/offline is another example, right now all the apps hook up to
> dbus, parse the signals coming from network manager and perform the
> actions, why is there no where to put a signal or a callback that simply
> says if you are on or offline (which can then have an NM and a
> traditional ifup/ifdown implementation).

This one is so little API it seems almost trivial to put in gtk (a 
simple GtkDesktop object that emits "logout" when the user logs out and 
"online-changed" when online status changes, for example - two signals 
is the whole API).

It seems clear that both of those are of general interest, so if you 
have to link to a libgnome to get them, then "GTK only apps" are broken.

There's never a world where we want every app to have a "GTK version" 
and a "GNOME version", right - we want to have a single platform where 
there's one kind of app.

So, app developers should not have to make this choice. If a hard 
dependency on XSMP or gconf is evil, then we should hack some way into 
the platform to use those things indirectly without a hard dep, then 
bury it all behind a nice API.

> Its not just about having the functionality in some library, its about
> making it easy and inviting to use for developers as well.

If developers up front have to make a meaningless "GTK app" vs. "GNOME 
app" choice, though, then we kind of instantly lose IMO.

> I think we learned that a badly designed one is a bad idea.

Agreed, but to me "badly designed" = "has no definition"

If we can't look at a piece of functionality and say which lib it goes 
in (regardless of how it's implemented or what it depends on), then the 
lib boundaries are screwy/overlapping/don't make any sense.

> > Then it's very clear how to decide where a given thing goes:
> >    - API sucks or isn't ready to support -> internal / not in platform
> >    - API intended for all apps to use -> gtk stack
> >    - API related to specific application domain or kind of application ->
> >      special library for that domain
>
> This last item is the thing that causes fragmentation and confusion.
> > From an outsiders point of view libmenu, libstartupnotification,
> enforcing lockdown policy by manually watching gconf keys is hard to
> figure out (and error prone). 

libmenu and libstartupnotification are not examples of my last point 
really. What I mean here would be something like "document editing apps" 
or "panel applets" or "apps that process XML"

libmenu and libstartupnotification are "parse freedesktop menu gunk" and 
"do startup notification lowlevel protocol handling" - neither of those 
tasks is something an app developer wants to do at all.

For adding an app to the menus or handling startup notification for 
launched windows, I think we're talking something virtually all apps 
want to do, it should just be in the single common platform (call it gtk 
or gnome).

For implementing a new kind of menu like slab, I think we're talking a 
very special-interest API; maybe there's 
libimplement-your-own-desktop-components or maybe we just say if you're 
coding desktop components you have to use low-level APIs or even 
internal APIs.

For lockdown, I think that could be a pretty large API that might merit 
its own standalone lib for apps that decide to fool with lockdown; or, 
it could be something that gtk has magic built-in support for to avoid 
GnomeLabel. Either way is sane. I don't see what's "gnome" about it 
though ;-) is GNOME pro-lockdown and GTK is anti-lockdown?

> > To me the main reason for an integrated/complete gtk stack is ease of 
> > use; it makes things _much_ less confusing if you can just point to one 
> > API and set of docs on how to write an app. It's a disaster to have 
> > things like GtkLabel vs. GnomeLabel or whatever, and that overlap is 
> > inevitable if the platform isn't coordinated in one spot.
>
> You're arguing for a single monolithic library it would seem; i'm
> arguing for 2 (or a very few) to allow for some sensible separation. 

What's the separation though? I just don't see "gtk vs. gnome" as a 
sensible one. I can think of hundreds of good library definitions but 
that isn't one of them ;-)

I'm not arguing monolithic lib (don't care about how many files are on 
disk), I'm arguing that there's one platform, call it Linux or GTK or 
GNOME or X, and there's one clear way to write apps for it. There may be 
optional platform components to choose among, but they should make sense 
to me as an app author - cross platform vs. not cross platform, need 
lockdown vs. don't care, etc. Those are things an app author cares about.

I think by "libgnome" people mean lumping together:
 - libnotcrossplatform-x-desktop-specific-apis
 - libsetup-gtk-hooks-to-use-gconf-and-vfs
 - libwidgets-preconfigured-to-use-gconf-lockdown
 - libthis-crap-sucks-too-badly-to-get-past-matthias-and-owen
 - libimplement-your-own-desktop-components
 - ...

Which results in the huge mess we've always had in libgnome* ...

Fixing the gconf and gnome-vfs situation would nicely nuke several of 
those categories, leaving a couple well-defined libraries outside gtk 
that would be just fine to have.

Anyway... it's not like it can happen one way or the other unless 
someone is stepping up to do a lot of work... gconf/gnome-vfs won't 
self-repair, and a libgnome won't self-maintain...

Havoc