no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Tue, 2011-05-10 at 20:51 +0100, Bastien Nocera wrote: On Tue, 2011-05-10 at 15:49 +0200, Michael Terry wrote: Hello! You may remember me as the bloke that proposed the Déjà Dup backup tool as a GNOME module a little back, right as modules were being reorganized. I've been encouraged to try again as a Feature. I don't fully understand the process, but I gather an email to this list starts it off. Here's a quick thousand foot view: * Homepage here: https://launchpad.net/deja-dup * It's a backup program aimed at non-technical users. * It's a graphical wrapper and policy manager for the backup program duplicity. * It's included by default in Fedora 13 on and will be default in Ubuntu 11.10. * It follows the GNOME schedule and best practices already. For the next major version (20.0), I've done a redesign aimed at making it more invisible and appear as part of the OS. I've made it live just as a control center panel and removed some branding to look a bit less like a separate app. See http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Because people carried on using the API despite being told it was going away, the GNOME control-center library isn't exported any more in master. That doesn't mean that the functionality shouldn't be in the control-center, but the integration needs to be even better within GNOME for us to add it there, including design, competitive research, etc. snip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:55 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. I understand it's frustrating, but I don't remember anyone asking whether this API was considered stable, or anything of that kind. We have a couple of people working close to full time on the control-center, so those questions would certainly get answered. We thought that third-party developers would put some work into integrating their functionality within the control-center, instead, we were stumped when we saw the Input methods panel, which was a straight port from GNOME 2.x instead of something integrated in the Region Language panel. hmm, where's that Input methods panel code? We indeed want it go through design and integrated into the Region Language panel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Mon, 2011-05-16 at 11:31 +0200, Rodrigo Moya wrote: On Wed, 2011-05-11 at 11:55 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. I understand it's frustrating, but I don't remember anyone asking whether this API was considered stable, or anything of that kind. We have a couple of people working close to full time on the control-center, so those questions would certainly get answered. We thought that third-party developers would put some work into integrating their functionality within the control-center, instead, we were stumped when we saw the Input methods panel, which was a straight port from GNOME 2.x instead of something integrated in the Region Language panel. hmm, where's that Input methods panel code? We indeed want it go through design and integrated into the Region Language panel It was in the im-chooser-gnome3 package in Fedora 15, which has since been disabled. The source still lives in im-chooser upstream: https://fedorahosted.org/im-chooser/wiki/ImChooser Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On 12 May 2011 20:52, Sergey Udaltsov sergey.udalt...@gmail.com wrote: For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences from scratch, rather than building on the gnomecc work. They are doing that anyway, and there is nothing we can do to stop them. Why are they doing that? Isn't that a very important question? Is just just because of them - or is it about GNOME as well? If distros tend to ignore the things that GNOME provides - perhaps, GNOME provides something that is not easy to use/customize? (moblin + maemo == meego, so you've really only got one example there) FWIW, the netbook spin of MeeGo uses gnome-control-center. We patch some capplets and replace others (i.e. display settings, our display capplet only supports clone) and are very pleased that we can drop in new capplets because it installs the library headers... Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On 13 May 2011 09:49, Sergey Udaltsov sergey.udalt...@gmail.com wrote: capplet only supports clone) and are very pleased that we can drop in new capplets because it installs the library headers... Thanks, Ross, for illustrating the real downstream POV. Do I understand it right that gnome3 approach to g-c-c extension (patching only) is going to make your life harder but would not stop you from putting your bits into g-c-c? Hypothetically speaking, we'd have to patch g-c-c to install the headers so that the out-of-tree capplets that we have could be built. As someone who works on a platform heavily based on GNOME technologies, the ability to build capplets out-of-tree is incredibly useful. I can understand the desire for the preferences panel to not be a random collection of apps, but I'd be surprised if any distribution that does real customisation of the platform will get by without patching g-c-c at all. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Hi, Sriram Ramkrishna wrote: I think I understand the system settings.. it is in fact system settings, settings that change how your system behaves. It isn't exactly a place for apps to put themselves. And yet some apps can be considered part of the system - IM, back-up, even things like email calendaring. And then there are apps that provide system services (things like an onscreen keyboard, screenshots, an alternative way to share files, a new IM service, an application-specific screensaver, an alternative search/indexing tool, etc). If we hard-code what GNOME supports into the design, when the needs evolve then we need a centralised decision for each new need. Better to provide a way for applications to integrate with system settings, and provide clear guidelines in the HIG on when doing so is appropriate, no? Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. Thanks, Ted signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 3:27 AM, Dave Neary dne...@gnome.org wrote: considered part of the system - IM, back-up, even things like email calendaring. We're trying very hard to make this line stronger, for multiple reasons. There are definitely still some blurry parts - Evolution is an app but the OS talks to it to display calendaring data for example. And then there are apps that provide system services (things like an onscreen keyboard, screenshots, an alternative way to share files, a new IM service, an application-specific screensaver, an alternative search/indexing tool, etc). Where we want to get to is that there are really just three things: * Apps * Extensions * The OS Most of what you're talking about here would fall under extension. If we hard-code what GNOME supports into the design, when the needs evolve then we need a centralised decision for each new need. Better to provide a way for applications to integrate with system settings, These aren't applications, and no - we don't want to encourage apps to drop things in system settings. As far as helping out extension authors - yes, I think that has value, but it's not as important as moving GNOME away from the bucket of parts model is. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 3:37 AM, Ted Gould t...@gould.cx wrote: Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. For Deja Dup? Just make its preferences part of the app - seems way saner to me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 09:37 +0200, Ted Gould wrote: On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. For the gnome-control-center, if it's worth having, it should be worth having upstream, and in gnome-control-center directly. If it's not something that's worth having upstream, then you should probably look at integrating it elsewhere, ie. in a separate application. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Le jeudi 12 mai 2011 à 13:48 +0200, Gendre Sebastien a écrit : System-config-* are not only one: Lirc settings? Boot (Grub+Plymouth) settings, etc. Recently, I read in Phoronix that AMD want to add the support of all these future CPU to the Free (as Freedom) bios/EFI nammed Coreboot. Some settings of this bios/EFI can be set from the operating system. So, we can have a panel for some basic settings in system settings. But only if we have this bios/EFI. How can we do that if we can't do a 3rd-party panel? With 3rd-party panel don't possible we are sure to broke these futures works, only for block some hypothetical problem. I don't think it's a good Compromise. I guess in the designer's mind, the two tools you cite are too advanced to be part of the control center. No normal user is going to need to tweak the BIOS settings, and actually I think that's exactly the kind of panel we want to block out of the control center. For system-config-printer, it might not be as clear a choice, but probably if important features are missing, they should be added to the Printing panel. And if they're not really needed for most people, it's OK for admins or geeks to use a separate tool. (Same for firewall.) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 16:21 +0200, Milan Bouchet-Valat wrote: Le jeudi 12 mai 2011 à 13:48 +0200, Gendre Sebastien a écrit : System-config-* are not only one: Lirc settings? Boot (Grub+Plymouth) settings, etc. Recently, I read in Phoronix that AMD want to add the support of all these future CPU to the Free (as Freedom) bios/EFI nammed Coreboot. Some settings of this bios/EFI can be set from the operating system. So, we can have a panel for some basic settings in system settings. But only if we have this bios/EFI. How can we do that if we can't do a 3rd-party panel? With 3rd-party panel don't possible we are sure to broke these futures works, only for block some hypothetical problem. I don't think it's a good Compromise. I guess in the designer's mind, the two tools you cite are too advanced to be part of the control center. No normal user is going to need to tweak the BIOS settings, and actually I think that's exactly the kind of panel we want to block out of the control center. The only settings we might want to change would be what to boot on, which would be part of a way to select the default OS to boot. This was discussed when we removed the restart menu item, as most of the time, you'll want to restart the computer in another OS, or to update your system. For system-config-printer, it might not be as clear a choice, but probably if important features are missing, they should be added to the Printing panel. And if they're not really needed for most people, it's OK for admins or geeks to use a separate tool. (Same for firewall.) Exactly. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Hi, Bastien Nocera wrote: On Thu, 2011-05-12 at 09:37 +0200, Ted Gould wrote: Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. For the gnome-control-center, if it's worth having, it should be worth having upstream, and in gnome-control-center directly. In the context of Ted's request, one obvious case to bear in mind would be integrating file sharing via Ubuntu One. That is a system service on Ubuntu, and should obviously have its preferences in the System preferences-Sharing panel. Is this the kind of thing you would accept upstream, or is it better to provide a hook for Canonical to do so easily downstream? Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Hi, Colin Walters wrote: On Thu, May 12, 2011 at 3:27 AM, Dave Neary dne...@gnome.org wrote: If we hard-code what GNOME supports into the design, when the needs evolve then we need a centralised decision for each new need. Better to provide a way for applications to integrate with system settings, These aren't applications, and no - we don't want to encourage apps to drop things in system settings. There is a world of distance between disallow, allow, but discourage and encourage. I definitely think that there's value in having a firm hand over preferences, and (say) defining all of the top level preference categories - I also think there's value in allowing applications to add preferences inside a given panel, and providing firm guidelines for when that's appropriate and how to do it well. As far as helping out extension authors - yes, I think that has value, but it's not as important as moving GNOME away from the bucket of parts model is. For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences from scratch, rather than building on the gnomecc work. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 16:44 +0200, Dave Neary wrote: Hi, Bastien Nocera wrote: On Thu, 2011-05-12 at 09:37 +0200, Ted Gould wrote: Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. For the gnome-control-center, if it's worth having, it should be worth having upstream, and in gnome-control-center directly. In the context of Ted's request, one obvious case to bear in mind would be integrating file sharing via Ubuntu One. That is a system service on Ubuntu, and should obviously have its preferences in the System preferences-Sharing panel. I don't know about the implementation, but the intent behind the design of that panel was to allow different sharing services to be added to it (just like Ubuntu One). See: http://live.gnome.org/Design/SystemSettings/PrivacyAndSharing Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 10:50 AM, Dave Neary dne...@gnome.org wrote: Hi, For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences from scratch, rather than building on the gnomecc work. They are doing that anyway, and there is nothing we can do to stop them. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 16:02 +0100, Allan Day wrote: On Thu, 2011-05-12 at 16:44 +0200, Dave Neary wrote: Hi, Bastien Nocera wrote: On Thu, 2011-05-12 at 09:37 +0200, Ted Gould wrote: Could someone please articulate the GNOME position for downstream distributors of GNOME technologies? It seems to me the previous position was to use the extension points instead of doing vendor patches. Yet, without extension points it seems that vendor patches are the only solution there. For the gnome-control-center, if it's worth having, it should be worth having upstream, and in gnome-control-center directly. In the context of Ted's request, one obvious case to bear in mind would be integrating file sharing via Ubuntu One. That is a system service on Ubuntu, and should obviously have its preferences in the System preferences-Sharing panel. I don't know about the implementation, but the intent behind the design of that panel was to allow different sharing services to be added to it (just like Ubuntu One). See: http://live.gnome.org/Design/SystemSettings/PrivacyAndSharing Exactly. It's also needed for our core code, as we'll want to make most of that stuff dependent on the backend being available. Eg. if rygel isn't installed, we wouldn't show the configuration for it (or show it in such a way that it was obvious how it could be enabled). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 16:50 +0200, Dave Neary wrote: Hi, Colin Walters wrote: On Thu, May 12, 2011 at 3:27 AM, Dave Neary dne...@gnome.org wrote: If we hard-code what GNOME supports into the design, when the needs evolve then we need a centralised decision for each new need. Better to provide a way for applications to integrate with system settings, These aren't applications, and no - we don't want to encourage apps to drop things in system settings. There is a world of distance between disallow, allow, but discourage and encourage. I definitely think that there's value in having a firm hand over preferences, and (say) defining all of the top level preference categories - I also think there's value in allowing applications to add preferences inside a given panel, and providing firm guidelines for when that's appropriate and how to do it well. As far as helping out extension authors - yes, I think that has value, but it's not as important as moving GNOME away from the bucket of parts model is. For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences from scratch, rather than building on the gnomecc work. No, they would probably end up making the headers available, and build on that. I don't see the problem here, if they actually intend on replacing most of the work, they'll probably be patching out some of the panels, and modifying some others. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences from scratch, rather than building on the gnomecc work. They are doing that anyway, and there is nothing we can do to stop them. Why are they doing that? Isn't that a very important question? Is just just because of them - or is it about GNOME as well? If distros tend to ignore the things that GNOME provides - perhaps, GNOME provides something that is not easy to use/customize? Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 14:52, Sergey Udaltsov sergey.udalt...@gmail.com wrote: For something like this, I have a feeling we may only get one chance. If you don't allow any differentiation on top of GNOME, there is at least one distribution that will just do preferences differently ignore control-center. And I can imagine that future environments along the lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences from scratch, rather than building on the gnomecc work. They are doing that anyway, and there is nothing we can do to stop them. Why are they doing that? Isn't that a very important question? Is just just because of them - or is it about GNOME as well? Because we don't have a mobile focus yet? Sure that would be about us. But the lack of mobile focus has nothing to do with this thread. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. while I'm not sure making the API private is the best idea, I really understand the reasons behind that decision, which is to not allow for a control-center crowded with lots of crazy panels, specific to applications. But backup is indeed something that makes a lot of sense as a System Settings panel, so I think it could probably be integrated into gnome-control-center itself. So, what are the dependencies the c-c panel in Deja Dup has? So, getting some design for this would be a good thing, so that we can start integrating it into the control center itself. Also, another solution might be to keep the g-c-c API public, but have a whitelist, so that we just list there the panels that we bless and that will be loaded in the g-c-c shell. Others would just be ignored, and so distributions can choose to add the panels they want to the whitelist. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Il giorno mar, 10/05/2011 alle 21.51 -0500, Jason D. Clinton ha scritto: On Tue, May 10, 2011 at 19:15, Luca Ferretti lferr...@gnome.org wrote: #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition There is no GNOME Desktop module; we now have only core, platform and bindings. What are you speaking of? In fact I wrote GNOME Desktop modules, I suspect we still have a GNOME Desktop project and two or more modules :P However, as I said, I could missed something in latest weeks, but I'm sure the transition from external/platform/desktop/admin/development to core/other (where other mainly means applications) is still not complete. , as well as with the idea of GNOME as platform for everyone What is this and where was it proposed? If not, what is GNOME? A self-sustained, self-contained project? Of course it's a great desktop for end users, but IMHO it's also -- or it should be -- an opportunity for developers. External developers. I.e. people that create software outside git.gnome.org. People that create software for fun, for profit or for funprofit. So I suspect there is no need to propose now GNOME as platform for everyone, it should be for everyone from its own creation. . This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. No, we do not have any such plans to approve or disapprove of modules. If they are outside of core, platform or bindings, the only official designation is that they might be featured in our marketing. That's it. We do not bless modules any more. Oh, sorry, then I used the wrong word. Please consider approved==featured. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? That's a technical problem, not political. I don't understand. What do you mean with technical and political? For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? Again, technical. Again, I don't understand. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
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
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. That will hopefully be superseded by the Web Accounts panel David is working on. Although I endorse design of the core components, I don't think it has to require the component to exist in gnome-cc. Furthermore, this seems like a fairly arbitrary limitation. Both major non-free desktops permit applications to install control-center. That's because Apple and Microsoft probably wouldn't be very receptive to adding functionality they don't have control over to the control-center. The control-center is still open source, and you can revert the patch that will make the library private, or, better, you can patch support for your functionality in the system settings and ask for integration upstream. Leaving the door open to the developer community to add new tabs gets us in the same tough spot as during the GNOME 2.x days. You end up with an unwieldy number of panels, and very little thought it what should go where. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 10:14 +0200, Rodrigo Moya wrote: On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. while I'm not sure making the API private is the best idea, I really understand the reasons behind that decision, which is to not allow for a control-center crowded with lots of crazy panels, specific to applications. But backup is indeed something that makes a lot of sense as a System Settings panel, so I think it could probably be integrated into gnome-control-center itself. So, what are the dependencies the c-c panel in Deja Dup has? So, getting some design for this would be a good thing, so that we can start integrating it into the control center itself. Also, another solution might be to keep the g-c-c API public, but have a whitelist, so that we just list there the panels that we bless and that will be loaded in the g-c-c shell. Others would just be ignored, and so distributions can choose to add the panels they want to the whitelist. If the whitelist is changeable (well, it always is, really), you lose. You're just shifting the responsibility from the upstream maintainers to the downstream maintainers. But it will still be upstream getting the blame for the bad design, eg. GNOME will be blamed for the system settings being a random collection of bits, when we're designing an OS. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. That will hopefully be superseded by the Web Accounts panel David is working on. But shouldn't we wait that the Web accounts panel is actually a full super-set of Empathy's panel (and not just some mockups) before removing the lib? G. -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 13:05 +0200, Guillaume Desmottes wrote: Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. That will hopefully be superseded by the Web Accounts panel David is working on. But shouldn't we wait that the Web accounts panel is actually a full super-set of Empathy's panel (and not just some mockups) before removing the lib? Of course, yes. And I didn't have time to work on moving gnome-bluetooth into the control-center either. I guess this'll serve as a warning to people who wanted to install their own panels. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, May 11, 2011 at 7:05 AM, Guillaume Desmottes gdesm...@gnome.org wrote: Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : That will hopefully be superseded by the Web Accounts panel David is working on. But shouldn't we wait that the Web accounts panel is actually a full super-set of Empathy's panel (and not just some mockups) before removing the lib? No. We don't want the crazy (sorry...) list of chat protocols in there, I think. The way I envision this to work for both empathy and for evolution is that the apps will pick up configuration for the major web accounts (google, facebook,...) from the web accounts panel, but still offer their own configuration for things like bare imap (in evo) or irc (in empathy). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: Although I endorse design of the core components, I don't think it has to require the component to exist in gnome-cc. Furthermore, this seems like a fairly arbitrary limitation. Both major non-free desktops permit applications to install control-center. That's because Apple and Microsoft probably wouldn't be very receptive to adding functionality they don't have control over to the control-center. I cannot say for Apple but I've seen drivers and applications that modify Windows Control Panel (i.e. add components). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Em Qua, 2011-05-11 às 11:37 +0200, Luca Ferretti escreveu: 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 :) Just because deja-dup depends on duplicity doesn't mean the control center panel needs to as well. It doesn't even have to depend on deja-dup, instead proposing its installation like Totem and file-roller handle non-installed formats. 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. I think the starting point here is not a negative point of view, it's how GNOME evolved from 2.0 to 2.32 as shipped in most GNOME distributions. Inviting application developers that want proper integration with GNOME to work with GNOME designers is a perfectly valid way to handle this situation. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Le mercredi 11 mai 2011 à 08:44 -0400, Matthias Clasen a écrit : On Wed, May 11, 2011 at 7:05 AM, Guillaume Desmottes gdesm...@gnome.org wrote: Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : That will hopefully be superseded by the Web Accounts panel David is working on. But shouldn't we wait that the Web accounts panel is actually a full super-set of Empathy's panel (and not just some mockups) before removing the lib? No. We don't want the crazy (sorry...) list of chat protocols in there, I think. The way I envision this to work for both empathy and for evolution is that the apps will pick up configuration for the major web accounts (google, facebook,...) from the web accounts panel, but still offer their own configuration for things like bare imap (in evo) or irc (in empathy). And what happen if Empathy fades away, if Gnome Shell becomes the Telepathy Handler ? Does it mean Gnome will no longer support less known protocols ? Nicolas signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Hi Luca, On Wed, May 11, 2011 at 2:37 AM, Luca Ferretti lferr...@gnome.org wrote: 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. I think I understand the system settings.. it is in fact system settings, settings that change how your system behaves. It isn't exactly a place for apps to put themselves. That said, we don't really have a proper forum to educate developers on how to write applications the GNOME 3 way. I realize we direct people to #gnome-design, but that's not really enough. To look at the big picture a bit, if we were to construct a life cycle of a GNOME application on how a developer goes about writing something in GNOME 3, we aren't going to get very far. For instance, developer.gnome.org is not anywhere on the gnome 3 site so an app developer at the moment really has to work at getting the information they need to get going. That's something some of us will need to work on... A simple construction of: in GNOME 3 - where do I store configurations? In GNOME 3, you must store configurations in gsettings and stored used in edit-preferences menu items. If you're app is a part of core GNOME 3, you may put your settings in system preferences Would help I think in giving application developers an idea where to do put their settings and avoid the abuse of system settings. You can illustrate using good applications that do it properly like say Rhythmbox and Totem. In the end, nobody can stop people from abusing the system settings if they wanted to. The source is out there and distros can just as easy revert whatever we do. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. That will hopefully be superseded by the Web Accounts panel David is working on. The last I heard, David's design was only for unifying, single-sign-on accounts such as Facebook and Google. Things that were pure IM accounts would still be in a separate capplet. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Wait! Maybe I missed something (busy weeks, sorry), but... #1 -- was this announced/proposed to desktop-devel-list? #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 )? #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition, as well as with the idea of GNOME as platform for everyone. This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Wait! Maybe I missed something (busy weeks, sorry), but... #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. #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. #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition, as well as with the idea of GNOME as platform for everyone. This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? 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. 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. Currently, there are 2 control-center modules that live outside System Settings, Bluetooth and the ibus configuration. The former should be merged in, and the latter should be merged with the layouts tab in region language, as designed. 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. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. ~ Although I endorse design of the core components, I don't think it has to require the component to exist in gnome-cc. Furthermore, this seems like a fairly arbitrary limitation. Both major non-free desktops permit applications to install control-center. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Tue, May 10, 2011 at 19:15, Luca Ferretti lferr...@gnome.org wrote: #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition There is no GNOME Desktop module; we now have only core, platform and bindings. What are you speaking of? , as well as with the idea of GNOME as platform for everyone What is this and where was it proposed? . This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. No, we do not have any such plans to approve or disapprove of modules. If they are outside of core, platform or bindings, the only official designation is that they might be featured in our marketing. That's it. We do not bless modules any more. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? That's a technical problem, not political. For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? Again, technical. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
