Re: gnome desktop integration library

[JP Rosevear <jpr novell com>]

On Tue, 2006-09-05 at 13:45 -0400, Havoc Pennington wrote: 
> Vincent Untz wrote:
> > We've talked about this a few times, and I believe consolidating our
> > GNOME integration libraries makes sense. So we'd basically have GTK+
> > (and friends) and libgnome-integration (or whatever you call it) for
> > what can't go in GTK+. (okay, we also have gnome-vfs and some other
> > libraries...)
> 
> You could call it... libgnome!
> 
> This has never made sense to me - what would be not able to go in gtk or 
> other appropriate lib? There just isn't anything. I'd say the definition 
> of gtk is an API for writing GUI apps. So if something is usually needed 
> to write GUI apps, gtk should have it, or something is busted.
> 
> http://live.gnome.org/ProjectRidley breaks out these "B" and "C" 
> categories of X or GNOME specific stuff; I don't think that is a good 
> way to break it down. If a general-purpose app really needs particular 
> functionality, gtk has to provide some way for the app to do it, 
> cross-platform or not. There's a gdk/gdkx.h for a reason, and the file 
> selector can backend to gnome-vfs for a reason.
> 
> The better line is between stuff general-purpose apps need vs. more 
> limited-applicability or specialized APIs. For example, libpanel-applet 
> may not be general-purpose, it might be something used only to write 
> panel applets, a special kind of app. That argues for libpanel-applet 
> being its own separate lib since most apps won't need it.

> 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.

> Another way to put it: there's no possible objection to putting stuff in 
> gtk that doesn't also apply to putting stuff in a public GNOME platform API.
> 
> i.e. if the thing is not cross-platform in gtk, it's also not 
> cross-platform in libgnome. If the thing is broken or likely to change 
> in gtk, then it's also broken or likely to change in libgnome. Changing 
> the shared object really makes no difference.
> 
> 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.

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.

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).

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

> Thus, ProjectRidley...
> 
> > As to what to put in there: I'm opposed to gnome-desktop going there
> > since there's only one useful function there now (thanks to GKeyFile):
> > gnome_desktop_item_launch_on_screen(). Can we start a page like
> > http://live.gnome.org/ProjectRidley and list the potential stuff that
> > could go in this library?
> 
> Isn't the whole point of ProjectRidley that we already spent nearly a 
> decade learning that a (general purpose) desktop integration library was 
> a bad idea ;-) I thought the argument was finally settled...

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

> Here are some lines that make more sense to me:
>   - gtk/freedesktop stack - the general-purpose API needed by most
>     applications
>   - various special purpose but still supported/platform APIs - APIs for
>     doing certain things that many apps won't need to do
>   - gnome internal library or libraries - APIs used within gnome but not
>     "exported"

When trying out new experimental work, its often useful to have these
libraries exposed anyhow - for instance the "slab" that was developed at
novell was able to use libmenu, but it would be much nicer to have a
guaranteed, stable API for that.

> 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).  See your point below, modulo the
overlapping api's which is of course silly.

> 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. 

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