Re: gnome desktop integration library

[JP Rosevear <jpr novell com>]

The problem is, I've seen no unequivocal declaration about gtk+ and glib
accepting these higher level abstractions, so perhaps matthias can
comment, because historically this has not been the case and is a
primary concern for me at least.

-JP


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? 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
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
JP Rosevear <jpr novell com>
Novell, Inc.