Il giorno mer, 11/05/2011 alle 01.27 +0100, Bastien Nocera ha scritto: > On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote:
> > #2 -- will gnome-c-c module englobe _all_ chosen panels? who will > > approve them? g-cc maintainers? release team? design team? a pool on > > doodle.com :P )? > > Maintainers and designers. Maintainers meaning that if it's not > designed, it won't go in. So really, designers. Will designers approve external dependencies too? It's just an example, but... Deja-dup needs duplicity. Deja-dup, converted to "Backup" panel inside gnome-control-center, will make gnome-control-center depends on duplicity (unless maintainer will make it optional, but I suspect designers can say "we want this feature by design" and promote it to mandatory). gnome-control-center is part of GNOME Desktop core. GNOME Desktop core depends on duplicity... I love Aristotelian syllogism :) > The "System Settings" isn't a random dumping ground for preferences. If > we (we being the designers, and then the maintainers, in that order) > don't think that the setting belongs in the System Settings, then it > won't go in there. IIRC, I never seen this statement during 3.0 development. Nobody said "you will not able to plug third part panel to System Settings". It was proposed as "we are going to move from menus and separate dialogs to single window". Empathy and krb5-auth-dialog developed their own panels and nobody stopped developers to waste their own time... > For backup, as I mentioned, we're not averse to having backup, but the > preferences will need to go through design before that happens. > > As for "preyproject" (their website not working seriously hampering what > I could find out about it), it seems that most of the functionality > would be in the privacy and sharing panel. Those 2 was just examples of external stuff that could be better suited as system settings panel :) There are much more stuff outside and inside git.gnome.org :) > We started moving things into gnome-control-center so we could stop the > various panels looking like they were a hodge-podge of thrown together > bits. Opening the door to 3rd-party panels would 1) get us the bug > reports 2) destroy the work we carefully crafted. And closing the doors IMHO means to follow, sorry to be impolite and a little offensive, a really stupid and dumb path. You are proving a resource, but you don't want other developers and vendors will be able to take advantage of it. It resembles to me a childish "this is MY toy, I choose who can play". A diktat: in or out. More, you are staring from a negative point of view. Maybe someone will be able to provide a beautiful and well integrated external panel for system setting, deja-dup proposal is a perfect example. A project taking care to be well integrated in chosen design. It could be a win-win game. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list