Re: gnome desktop integration library

[Rodrigo Moya <rodrigo gnome-db org>]

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.
> 
panel applets, interaction with the panel, screensaver, etc, etc, are
not things that can go into GTK. If they can, then let's put them in
GTK, but so far it seems they can't.

This desktop integration library idea is not about putting all small
libs into one huge module, it is about having a library that apps would
use when tightly integrate into the GNOME desktop.

> 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.
> 
as more and more apps use D-BUS for desktop services, and since GTK
can't depend on D-BUS, we need a high level place to put those things,
instead of the current way of having lots of small libraries

> 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.
> 
see above :)

> 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...
> 
you are thinking about libgnome/ui, which have been a trash bin for
stuff not accepted in other lower level libraries, but as I said before,
this high level lib would contain things specific to GNOME (like talking
to desktop services) that are not general-purpose and cross-platform
enough for being in GTK.

> 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.
> 
right, GnomeLabel (or any similar "crappy" widget) won't be at all in
the library I am proposing.
-- 
Rodrigo Moya <rodrigo gnome-db org>