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 > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- JP Rosevear <[EMAIL PROTECTED]> Novell, Inc. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
