Re: gnome desktop integration library
- From: Havoc Pennington <hp redhat com>
- To: Vincent Untz <vuntz gnome org>
- Cc: Joachim Noreiko <jnoreiko yahoo com>, Mark McLoughlin <mark skynet ie>, Rodrigo Moya <rodrigo gnome-db org>, Control Center List <gnomecc-list gnome org>, desktop-devel-list gnome org, JP Rosevear <jpr novell com>
- Subject: Re: gnome desktop integration library
- Date: Wed, 06 Sep 2006 15:42:27 -0400
Vincent Untz wrote:
Sure, some (or most?) of this specific stuff could go in GTK+ or a GTK+
module. But I'm not convinced we can come with a good cross-platform API
for lockdown (since not all platforms will be able to lock the same
things), or that the applet API should be in a separate library
(especially if we're going with a new cool API that applications will
want to use instead of adding icons in the notification area).
There are obviously some _inherently_ GNOME specific APIs, mostly to do
with writing extensions to desktop components (panel applets, nautilus
extensions). It makes a heck of a lot of sense to me to ship each lib in
a tarball with the thing it extends, but a single libgnomeextension is I
guess plausible too - that's a bounded, understandable library
definition - "APIs for extending GNOME desktop components"
If you look at for example the GdkSession sketch I posted though, people
seem to feel that is GNOME specific for some reasons I don't understand
at all; the functionality is completely implementable on Windows and KDE
I know, and probably other platforms too.
Lockdown I don't know enough about what the API would be like to really
have a perspective on, but I think most apps would prefer a lib that at
least compiled and worked cross-platform (even if the implementation on
some platforms was "nothing is ever locked down").
Anyway - the basic point I'm making in this whole thread is, have
logical, defined module boundaries. If you can't pretty easily say what
does and doesn't go in a library, that library is busted.
And secondarily, pick the logical, defined module boundaries that make
sense, then talk people into them. There's no point assuming from the
get-go that the right solution isn't possible.
Bryan mentioned some experiment with monkeys where they would spray all
the monkeys with water whenever a monkey went up a ramp or something
like that; so all the monkeys learned to turn on any monkey that went up
there. Over time, they replaced all the monkeys one-by-one, so
eventually no monkey in the cage had ever been sprayed or knew why it
was bad to go up the ramp. But they still all turned on any monkey who
tried to go up it.
The libgtk/libgnome split is kind of like this in my opinion; it's
basically a historical legend that won't die. Nobody would design things
this way from scratch, nor is there any major issue with fixing it
today. In fact quite a few examples of how to fix it exist (file
chooser, cairo, etc.).
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]