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