Re: gnome desktop integration library
- From: Havoc Pennington <hp redhat com>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Mark McLoughlin <mark skynet ie>, Vincent Untz <vuntz gnome org>, Control Center List <gnomecc-list gnome org>, desktop-devel-list gnome org
- Subject: Re: gnome desktop integration library
- Date: Tue, 05 Sep 2006 19:33:30 -0400
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.)
] [Thread Prev