Re: gnome desktop integration library

[Havoc Pennington <hp redhat com>]

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.

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.

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

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"

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

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.

btw, it's not like I'm hacking on any of this so don't let me stop 
anyone from doing anything, I just felt obliged to chime in with a quick 
"haven't you kids learned anything from the last decade?" now that I'm 
old and cranky.

Havoc