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
