Re: gnome desktop integration library

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>

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