Re: gnome desktop integration library

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2006-09-05 at 19:33 -0400, Havoc Pennington wrote:
> 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?
>
because of the D-BUS dependency? It makes sense to have, as you
mentioned, screensaver stuff in GTK, but the problem is the same as with
GConf. Until GTK can depend on GConf, gnome-vfs, D-BUS, etc, we'll need
a place to put all the stuff that depends on that and which is used to
talk to GNOME desktop components.

> > 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.
> 
it's not an assumption, I've heard it many times. If I'm wrong, then
please let me know so that I change the plan to put all this into
GTK/glib rather than in a high-level library.

> > 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 if the lib is for 'integration into the GNOME desktop', why would we
call it something related to its non-cross-platform or generic?

> 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 ;-)
> 
again, I think you are thinking about this lib like a place to put
things like what there is now in libgnome/ui. And no, this is not my
intention at all. My idea is to put interfaces to GNOME services
(screensaver, panel, etc), and policy-related implementations (lockdown,
for instance, as JP said in a previous mail) and any other thing that
might come up in the future.

> > 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 think you are not getting my point, the idea of this lib is not to
have non-cross-platform, unportable stuff, it is to provide a single
point for developers to use the GNOME components from their apps. That
is, instead of saying "use gnome-desktop for reading .desktop files,
gnome-menus for reading dirs with .desktop files, libpanel if you want
to talk to the panel, libgnome-settings-daemon if you want to
communicate with the settings daemon, xxx to do xxx, etc, etc", we would
say "use libwhatever to use public GNOME components' interfaces"

I hope my explanation was better this time.
-- 
Rodrigo Moya <rodrigo gnome-db org>