Re: gnome desktop integration library


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


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