Re: gnome desktop integration library

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

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]