Re: gnome desktop integration library

[Havoc Pennington <hp redhat com>]

Hi,

Rodrigo Moya wrote:
> 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.

You're just taking this for granted. It's not like there's some a priori 
definition of "stuff that can go in gtk" - the single platform (call it 
gtk) should have whatever makes sense to have in there. Which is 
anything that a general-purpose GUI desktop app would typically want to do.

I think "write a panel applet" should be its own lib because that's not 
something most apps want to do, but it is a well-defined thing that a 
specific kind of app wants to do. So it's an optional platform component 
and it's clear when you want it.

I see nothing wrong with a gtk_get_screensaver_is_active() function. 
Lots of apps need that, why would gtk be against this? As an app 
developer unfamiliar with how the platform is implemented on the 
backend, why would I expect to find this in a separate lib from gtk?

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

But as an app developer, how do I decide whether I want to do that? Do 
we need two versions of every app, one that "tightly integrates" and one 
that does not? Why can't the library figure this out for me?

As an app developer I'd say I clearly want to _both_ tightly integrate, 
_and_ be cross platform, _and_ have only solid, stable dependencies. I 
don't want to choose among these things.

> 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

Why can't gtk depend on dbus? How do those reasons not apply to libgnome?

I don't know, I'm asking. But there's no reason to just make an 
assumption up front that gtk can't depend on dbus, or that gnome should.

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

If the lib is for not-cross-platform not-general-purpose APIs, then I'd 
suggest calling it something related to that, or calling it some 
meaningless name and describing it as that...

but how many app developers, given an honest description of a lib as 
"unportable special-purpose APIs," will choose to use this lib? And is 
there any way to limit how big such a lib gets? There are an awful lot 
of unportable special-purpose APIs in the world ;-)

> right, GnomeLabel (or any similar "crappy" widget) won't be at all in
> the library I am proposing.

But why not? The question is what is the definition of this library. 
GnomeLabel was probably special-purpose and unportable ;-) I bet it also 
offered tighter GNOME integration.

(I don't honestly remember what the heck GnomeLabel was.)

Havoc