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: GNOME Feature Proposal: Backup
On 18 May 2011 13:21, Michael Terry m...@mterry.name wrote: 2) I'll move my mailing list to GNOME. That seems rather painless and seems to make it easier for GNOME people. It's super low traffic, so doesn't really matter. But I encourage people to make it high traffic. Just an overdue update that this happened! Subscribe away: https://mail.gnome.org/mailman/listinfo/deja-dup-list -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi! If they were fully integrated into gnome.org bugzilla well enough that the project was a first-class citizen, and integrated into gnome.org git well enough that translators could work in their usual way ... would there be any fragmentation problems? The question is highly hypothetical as both don't have the same features and will never be fully integrated. And if they would really use the same data - why bother using both? I realise that the integration doesn't yet exist, but bzr git mirroring is perfectly possible (Launchpad has done it in the other direction for years) and synchronising two sets of bug data is hardly advanced stuff. All we lack is someone with time on their hands :) You will never be able to have automatic two way synchronisation so that people can both commit and launchpad and gnome-git because then you would need to solve conflicts automatically, which doesn't work. Regards, Johannes 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: GNOME Feature Proposal: Backup
On Fri, May 20, 2011 at 10:32 AM, Allan Day allanp...@gmail.com wrote: Dave Neary wrote: snip Leaving aside because that's the way it is as a reason for a second, what are the potential issues we'd have using Launchpad? * Bug reporters would have to have an easy way to report bugs against Deja Dup through gnome.org * GNOME developers would need to reassign bugs to deja dup which were incorrectly assigned to another GNOME module * Deja Dup developers would presumably want to do the same thing in the other direction Are there others I'm missing? /snip * A way to subscribe/CC GNOME contributors to Deja Dup bugs * Need to be able to target bugs at specific GNOME releases * The release team needs to be able to mark and track release critical bugs (important ones, blockers, etc). I gather that this is currently done by querying Bugzilla. The latter two are essential, I guess. We also have the fragmentation issue to think about: if Deja Dup uses LP, what's to say other modules can't use it too? Or Source Forge? Or Google Code? Or Trac installations... If they were fully integrated into gnome.org bugzilla well enough that the project was a first-class citizen, and integrated into gnome.org git well enough that translators could work in their usual way ... would there be any fragmentation problems? I realise that the integration doesn't yet exist, but bzr git mirroring is perfectly possible (Launchpad has done it in the other direction for years) and synchronising two sets of bug data is hardly advanced stuff. All we lack is someone with time on their hands :) 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Dave Neary wrote: snip Leaving aside because that's the way it is as a reason for a second, what are the potential issues we'd have using Launchpad? * Bug reporters would have to have an easy way to report bugs against Deja Dup through gnome.org * GNOME developers would need to reassign bugs to deja dup which were incorrectly assigned to another GNOME module * Deja Dup developers would presumably want to do the same thing in the other direction Are there others I'm missing? /snip * A way to subscribe/CC GNOME contributors to Deja Dup bugs * Need to be able to target bugs at specific GNOME releases * The release team needs to be able to mark and track release critical bugs (important ones, blockers, etc). I gather that this is currently done by querying Bugzilla. The latter two are essential, I guess. We also have the fragmentation issue to think about: if Deja Dup uses LP, what's to say other modules can't use it too? Or Source Forge? Or Google Code? Or Trac installations... 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: GNOME Feature Proposal: Backup
On Wed, 2011-05-18 at 13:21 -0400, Michael Terry wrote: And also, does being in git imply that the translation team would automatically consider the module? yes, you will start getting translations as soon as it's there. It happened to me to several modules ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 19 May 2011 04:45, Allan Day allanp...@gmail.com wrote: These changes seem like good ones. Heh, well of course you think so. :) Though, I've gotten bad feedback about the feasibility of a round-trip bzr-git-bzr conversion. I may start small with just a git mirror. But moving bugs out of LP is a step too far for me. As would be carving up pieces of Deja Dup into other modules (like gnome-control-center). So I'll just keep chugging along as a separate app for now. But hopefully these changes will let the GNOME community become more involved if ya'll desire. As I've said previously, it would be great to have an integrated GNOME backup feature, and it would be cool to work together on this. The two issues you mention above seem to be blocking us though. Regarding bug tracking: I was waiting to hear some arguments about how Deja Dup could continue to use LP bug tracking and be a core GNOME module... if you do think that is possible, do make the case! Of course I think it's possible, but Olav made it clear that the issue was settled law. Assuming it's not, I see at least a couple options: A) GNOME devs could deal with it and realize that one more web account won't kill them. The ability to search and reassign bugs to deja-dup from within b.g.o don't seem like killer features to me. It must be an issue now with external dependencies and you live with it. B) We could have a deja-dup module in b.g.o as well as the canonical one in LP. LP has this cool feature to synchronize comments and such between a bug in LP and a bug elsewhere. It's turned off for b.g.o, but it may be possible that it could be turned on per-module. I'd have to look into it. Likewise, let's be clear about what's in the way of keeping Deja Dup as a single module: would whitelisting gcc panels solve that issue? Yes, as I've said in the g-c-c thread. Though the idea didn't get any traction. But again, not being Core isn't the end of the world. I'm content to remain a well-integrated (potentially-Featured) external app while doing what I can to reduce the barriers to collaboration with GNOME developers, designers, etc. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On Thu, May 19, 2011 at 09:22:40AM -0400, Michael Terry wrote: Of course I think it's possible, but Olav made it clear that the issue was settled law. Assuming it's not, I see at least a couple options: This is just the discussion period, not decision. At the moment, we want it on GNOME infra. But extdeps are somewhat different, etc. It was actually on the agenda of the release-team meeting to really clarify the requirements. Once that is clear I wanted to follow up with the outcome. Sorry for the mess. Non-GNOME infra is still difficult topic. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 19 May 2011 09:22, Michael Terry m...@mterry.name wrote: LP has this cool feature to synchronize comments and such between a bug in LP and a bug elsewhere. It's turned off for b.g.o, but it may be possible that it could be turned on per-module. I'd have to look into it. Not possible right now. :( I filed a bug with the Launchpad project about it: https://launchpad.net/bugs/785173 -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi, Michael Terry wrote: Though, I've gotten bad feedback about the feasibility of a round-trip bzr-git-bzr conversion. I may start small with just a git mirror. Just to provide some historical context: I recall one GNOME developer expressing his annoyance at having to sync his private git repository with svn via a gateway. It would not be unheard of for a maintainer to develop in another source control system and use some kind of gateway to publish on gnome.org Of course I think it's possible, but Olav made it clear that the issue was settled law. Leaving aside because that's the way it is as a reason for a second, what are the potential issues we'd have using Launchpad? * Bug reporters would have to have an easy way to report bugs against Deja Dup through gnome.org * GNOME developers would need to reassign bugs to deja dup which were incorrectly assigned to another GNOME module * Deja Dup developers would presumably want to do the same thing in the other direction Are there others I'm missing? Addressing those concretely: 1. We currently have a straightforward story for users with bug reports: Go to bugzilla.gnome.org, create an account, and report it there against the best module. Don't worry if you get it wrong, we'll reassign afterwards if you make a mistake. Using Launchpad for a core module would need either (a) a nice way to sync up bugzilla launchpad bugs comments, or (b) a new way to indicate to users where they should report a bug (a portal page? Maintenance issues to think about) 2. and 3. What does Launchpad Bugzilla offer in the way of transfering bug reports comments from one to the other? A) GNOME devs could deal with it and realize that one more web account won't kill them. The ability to search and reassign bugs to deja-dup from within b.g.o don't seem like killer features to me. It must be an issue now with external dependencies and you live with it. Sure - this is also an approach to consider. B) We could have a deja-dup module in b.g.o as well as the canonical one in LP. LP has this cool feature to synchronize comments and such between a bug in LP and a bug elsewhere. It's turned off for b.g.o, but it may be possible that it could be turned on per-module. I'd have to look into it. Something like this (ideally two-way) would be great. And would, I think, remove the biggest objection to using Launchpad for GNOME modules. 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: GNOME Feature Proposal: Backup
It seems discussion died down around this, which means the status quo of just a GNOME external app will prevail. But I'm going to go ahead and take some steps to increase potential cooperation between Deja Dup and GNOME, for those that are interested: 1) I'll try to stay more on top of the jhbuild moduleset. It got bit-rotten as Colin pointed out, but now it's up to date. 2) I'll move my mailing list to GNOME. That seems rather painless and seems to make it easier for GNOME people. It's super low traffic, so doesn't really matter. But I encourage people to make it high traffic. 3) I'll experiment with moving my trunk to GNOME git. This will let GNOME people more easily dip their toes in the Deja Dup waters. Ideally this will be as low-cost an experiment for me as possible, so I'm curious about other people having done similar conversions. I'll keep a bzr mirror in LP for existing developers. But could I move back to bzr and not lose anything? i.e. would a round-trip (bzr-git-bzr) imply some metadata loss? And also, does being in git imply that the translation team would automatically consider the module? But moving bugs out of LP is a step too far for me. As would be carving up pieces of Deja Dup into other modules (like gnome-control-center). So I'll just keep chugging along as a separate app for now. But hopefully these changes will let the GNOME community become more involved if ya'll desire. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Am 18.05.2011 19:21, schrieb Michael Terry: And also, does being in git imply that the translation team would automatically consider the module? Not automatically, you have to be added[1] to l10n.gnome.org [1]: http://bugzilla.gnome.org/enter_bug.cgi?product=damned-liescomponent=l10n.gnome.org -- Greetings, Sebastian Pölsterl signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 14 May 2011 00:32, Michael Terry m...@mterry.name wrote: Hrm. I do have a need to clean up the jhbuild sets. I also know that older modulesets should be pointing at the branches of DD, not trunk. I will fix that soon. Just FYI, I fixed up the modulesets. Now librsync is built for duplicity, DD has the correct gtk3-oriented dependencies, and DD points at the appropriate versioned branches for each moduleset. -mt ___ 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 GNOME Feature Proposal: Backup]
On Thu, 2011-05-12 at 22:58 +0100, Sergey Udaltsov wrote: We're not dictating anything; we're just making an awesome OS, the way we envision, period. Wait a sec. It was said (here and on IRC) that g-c-c wants to include only polished panels to g-c-c. Only panels that gnome UI specialists are happy with. It is a form of dictate - or I do not know what dictate is. Or did I misunderstand some statements? In a way, even HIG itself is a dictate - a relatively weak form of it (but at least put into the document, which is the best thing about HIG!) ___ well, it's really a way of asking people interested in having stuff in g-c-c to cooperate with GNOME designers and developers. Apart from that, that's how every piece of GNOME software works: maintainers include what they are happy with, not everything anyone wants to add. ___ 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 GNOME Feature Proposal: Backup]
Il giorno Fri, 13/05/2011 alle 18.26 +0100, Bastien Nocera ha scritto: The correct way to behave then is to work on the search backends, not to complain here. You have misinterpreted my words; It wasn't a complain for that specific events, it was an example (but I suppose we could cite/find others) about how upstream could be slow to accept some changes. Or refuse, but this is a different story... /Bastien, kernel, udev and X.org contributor because fixing things properly is important Sorry, I don't understand how this pedigree could be useful here. Are you saying a proper solution to search feature will need changes in kernel too? :) ___ 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 GNOME Feature Proposal: Backup]
On Sat, 2011-05-14 at 12:58 +0200, Luca Ferretti wrote: Il giorno Fri, 13/05/2011 alle 18.26 +0100, Bastien Nocera ha scritto: The correct way to behave then is to work on the search backends, not to complain here. You have misinterpreted my words; It wasn't a complain for that specific events, it was an example (but I suppose we could cite/find others) about how upstream could be slow to accept some changes. Or refuse, but this is a different story... /Bastien, kernel, udev and X.org contributor because fixing things properly is important Sorry, I don't understand how this pedigree could be useful here. It's just my way of showing that things can be achieved by draining the swamp. I'm certainly not the biggest contributor to draining the swamp, but it shows that even though my interests are on GNOME, work is still needed on the underlying layers to achieve things at the higher level. In the case of those particular modules, I had to contribute to all those, in addition to gnome-settings-daemon to make Disable touchpad buttons work on a variety of laptops. Are you saying a proper solution to search feature will need changes in kernel too? :) recursive mtime, and fanotify support in the kernel would certainly help startup performance, and indexing. 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 GNOME Feature Proposal: Backup]
Sergey Udaltsov [2011-05-12 20:45 +0100]: Technically, if the architecture only allows extension through patching (instead of extension points), it means the architecture is closed (that must be a highly offensive statement, if we're talking about free software). Also, that is a very effective way to alienate 3rd parties (app developers, distromakers). I suspect, that attitude in gnome possibly affected Canonical decision to drop gnome 3. Not at all. C/U did not drop GNOME 3, the reason why the current release does not have it was a timing/planning/manpower issue. GNOME 3 is landing in the development release as we speak. Please let's not make this appear as a we don't want to play with your toys any more kind of argument. :-) This would not only be totally stupid from our side, but we would also just shoot ourselves in the foot with that. Aside from that the technical issue remains that this does make it harder to customize c-c to a downstream's needs, of course. It's really good that the individual changes are being discussed here (deja-dup, etc.), and perhaps for the case of Ubuntu One we can even find some better solution than totally Ubuntu specific, but I'm afraid it is a fact that we will always have a need to do some customization (like adding our Additional Drivers, or at least brand Ubuntu One as such, etc.). We'll get along either way, I just think it is important for GNOME to understand that closing APIs like that won't really stop Ubuntu (or Meego, etc.) from changing it anyway. Thank you, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.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 GNOME Feature Proposal: Backup]
In a UDS session this week about this control center issue, one discussed idea was a hard-coded (in source) whitelist or brightlist. To be clear, a brightlist would be a set of plugins that appear at the top as part of the OS and there's some other section where everything else goes. A whitelist would instead just stop anything else from appearing. This way, GNOME designers can enforce a set of plugins that only they want for their OS. Since it's in-source, it would be difficult for random third parties to work around it. But at the same time, other distros that also believe themselves to be creating an OS can distro-patch the list and have the experience they want. Everyone wins, with exceedingly little technical effort. What do the g-c-c maintainers feel about that? -mt ___ 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 09:56:26AM +0200, Michael Terry wrote: Everyone wins, with exceedingly little technical effort. What do the g-c-c maintainers feel about that? So your suggestion is to still have new panels? The purpose of no external API is not to make it more difficult, but to ensure: - control center does everything it should - ensure functionality is available across distributions - relevant options appear in the place the design team thinks it should be; not in yet another panel So focus should be on ensuring that options are shown in the right places and that whatever functionality is needed, is added in control-center in a way it will work for all distributions. Having another panel does not provide a good user interface. As explained, no 'java options'. Even for firewall, if it makes sense, it should be shown where the designers think it makes sense (e.g. some system/network thing), not where it is technically easiest. It seems there is an assumption that no external API is meant to force; it is not. The purpose is to ensure that the control center options follows a logic (designed) structure; not have options all over the place. If you want additional option in Ubuntu, address this to either the Ubuntu design team or the GNOME design team. Then the options should be added whereever the design teams thinks it should go. -- Regards, Olav ___ 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: GNOME Feature Proposal: Backup
On 12 May 2011 17:05, Allan Day allanp...@gmail.com wrote: I presume you'd be happy for Deja Dup to become a GNOME Control Center panel? Depends on what you mean. I'm happy for Deja Dup to be shown as a panel in the control center. But it sounds like you're asking about actually putting it in the control center git tree? I guess I don't see the point. * I'd like to continue to support GTK-but-not-GNOME platforms (why not?) even if only as second-class citizens. So I'll probably add a preference dialog that simply wraps the deja-dup control panel for such cases. Having the panel be out-of-trunk makes that unnecessarily hard. * I assume the rest of deja-dup would be a separate module, so now it would be split across modules, losing the ability to share translations or logic. I'd have to write a library to share some of the logic bits. So that would be more work. * The only reason to be in tree that I can see is that g-c-c plans to drop the API for panels? But that is a separate thread. If Deja Dup is accepted, we'll need to work together and GNOME contributors (developers, designers, bug reporters and triagers, translators, documentors, etc) will want to contribute to Deja Dup. How will they do that? My intent is to achieve high levels of collaboration. I have lots of ideas about how the GNOME community and LP projects can have tighter integration. I can defend why LP works for me, but that's not entirely the point here I feel. It could be so easy to collaborate! We could mirror bzr trunk in git, grant permissions to bzr trunk to an automatically sync'd group on LP, grant permissions to the translation web UI+trunk to the GNOME translation team. I could move my mailing list. I like to think the project already works well with GNOME designers (you and I have done a review before). Etc. So the big question to GNOME is how much do ya'll want to avoid the extra step of such collaboration for Features you consider part of your core? Is that a hard-blocker? Who gets to decide if it is? I'm theoretically open to moving infrastructure, pending a weighing of benefits. But I'm also curious if GNOME is even theoretically open to me not moving. See my other message on the branding question - this isn't necessarily a problem. I'm just interested to hear your thoughts on how Deja Dup will be branding itself as a standalone application. I had envisioned the same way as a non-standalone app. It would appear as Backup to the user. Either as a standalone preference dialog or control center panel. But I've been thinking it needs to show its brand name at least once (I currently show it in the welcome screen). That way users know what they are getting. Now if your question is really about what that brand is (GNOME Backup vs Deja Dup) that's a different issue that I'm just now guessing you meant? I don't feel strongly on the name presented to users. I'm open to feedback here. It could maybe even be presented differently if deja-dup is a standalone app vs a panel? -mt ___ 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 GNOME Feature Proposal: Backup]
On 13 May 2011 10:31, Olav Vitters o...@vitters.nl wrote: So your suggestion is to still have new panels? Depending on whether you wanted to allow 3rd party panels, you could use a brightlist or a whitelist. But yes, a public API coupled with a whitelist to allow only design-approved external modules. It seems there is an assumption that no external API is meant to force; it is not. The purpose is to ensure that the control center options follows a logic (designed) structure; not have options all over the place. If you want additional option in Ubuntu, address this to either the Ubuntu design team or the GNOME design team. Then the options should be added whereever the design teams thinks it should go. Right. And this proposal was designed to allow each design team to decide their own OS's experience easily by patching the whitelist. The plan to drop the API adds a larger technical barrier that appears artificial. -mt ___ 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 12:47:52AM +0100, Sergey Udaltsov wrote:
I guess the questions like that will be discussed again and again. The
interaction between GNOME and distros is a very complex matter. On
Loads of distribution people are involved within GNOME. The only
problems occur with distributions which do not have the resources, or
actively prefer working outside of GNOME (e.g. Canonical, Mandriva at
the moment).
Pretty sure Fedora and openSUSE is fully aware of what the intend is.
Some distributions might not be aware yet, but things are still under
development. Not knowing is not bad; not everything has been defined
yet.
What you do see is various individuals talking about specific things
across distributions. Think e.g. the session handling of systemd.
political level, on user experience level, on technical level. Please
please please - put together the policy document. Even if its content
would make me and Luca unhappy - at least that would be some document
people could read, could refer to (may be, it would even make me shut
up:). At least I could send unhappy minority to read that document
when they WTF me (that happens a lot on linux.org.ru AKA Russian
Slashdot). Then they would decide if they want to stick with GNOME or
just move on - that might save d-d-l one day from the invasion of all
those unhappy heads.
I don't get at all what the purpose is (concretely) of the document. Nor
what contents it should have. What do you mean with policy? It feels
very vague and undefined ('interaction points'?).
http://live.gnome.org/GnomeOS
I think above is enough. We aim to have a nice OS. Distribution
differences are something to be avoided, not encouraged. I dislike that
I have a Mandriva control center. It is nice, but specific to Mandriva.
I don't see the benefit. I want a nice integrated experience, not a
collection of components.
Distributions can still change things as they wish, but that is not our
goal.
--
Regards,
Olav
___
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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 10:46:51AM +0200, Michael Terry wrote: Right. And this proposal was designed to allow each design team to decide their own OS's experience easily by patching the whitelist. The plan to drop the API adds a larger technical barrier that appears artificial. AFAIK, the API was only about new panels. I wrote a whole post (which I am not going to repeat) that new panels are not what is intended. As such, there is and was no API. -- Regards, Olav ___ 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: GNOME Feature Proposal: Backup
On Fri, May 13, 2011 at 10:38:09AM +0200, Michael Terry wrote: So the big question to GNOME is how much do ya'll want to avoid the extra step of such collaboration for Features you consider part of your core? Is that a hard-blocker? Who gets to decide if it is? I'm theoretically open to moving infrastructure, pending a weighing of benefits. But I'm also curious if GNOME is even theoretically open to me not moving. This depends if it is considered an external dependency or not. If you're an application: use whatever you want, though GNOME infra is preferred If you're external: use whatever you want, though GNOME infra or freedesktop.org is preferred If you're GNOME core: GNOME infra. GNOME infra ensures everyone in GNOME automatically can get involved (commit access, bugzilla, translators, etc), release-team has a good overview (we track everything in GNOME infrastructure, not anywhere else), we can assign GNOME milestones to stuff, etc. AKA: Network effect. Also: I'd consider Zeitgeist as (potential) external dependency. -- Regards, Olav ___ 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 GNOME Feature Proposal: Backup]
Distribution differences are something to be avoided, not encouraged. It is not for gnome to decide. See the messages from Ross. Differences are inevitable. Let's embrace differences, let's minimise patches. Let's be friendly to downstream. Anyway, since distros are patching in their capplets - gnome FAILED the main goal - to define the final experience. And that failure was unevitable. So closing apis is just a form of avoiding responsibility for the failure. I dislike that I have a Mandriva control center. It is unevitable with the current approach umho. ___ 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 GNOME Feature Proposal: Backup]
Il giorno ven, 13/05/2011 alle 00.51 -0400, William Jon McCann ha scritto: How about: raison d'être. What is our mission, what is our reason for existing? Is it to provide a gummy base for others to adapt, modify, and differentiate? No. Your own vision of open source is totally different from mine. Sorry. ___ 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 11:43:08AM +0200, Luca Ferretti wrote: So IMHO choosing a priori what people can do and what people can't do is... well, censorship, sorry. Matthias said maintaining meaningful boundaries between what is GNOME and what is not. Of course this is a way to maintain a strong identity[1], but how does it implies? That we have the Truth? And even if we had, we can't annoying restrain distros, third parties to modify and customize: this is a part of fundamental right of FLOSS. GNOME is provided under the GPL (and other FLOSS licences like LGPL). The control-center maintainers made a quick API for GNOME 3.0 only. Saying the removal is censorship? What about all the options that are not in the GNOME 3.0 control center? What about our license? What about a maintainers decision and the goal of a project? I think the last bit is the only one that the disagreement is about. The goal is shifting from a 'mix and match' components as you please towards relying more and more on specific components. Your definition of censorship applies to everything that a maintainer does. Not applying a patch or implementing a feature would also be censorship. GNOME is now way more design orientated; could also call it decisions.. or censorship. The latter has a strong emotional impression. I'd rather have people talk about the goal of GNOME without too much emotional implications. Too much emotions only leads to heated arguments and people not listening to eachother anymore. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 11:53, Gendre Sebastien ko...@romandie.com wrote: I'm agree with Luca: It would be better if split Déjà Dup with Gnome Backup. Also, we can have: - Gnome Backup as a G-C-C panel for Gnome Desktop. - Déjà Dup as a GTK+ Application for non-Gnome Desktop, ex for XFCE. One minor point about this: Deja Dup is GPL-3+. G-C-C is GPL-2+. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi Michael, Thanks for all of this. Let me reiterate that I *really* want to see Deja Dup in 3.2. We just need to figure out how to make it work. Michael Terry wrote: On 12 May 2011 17:05, Allan Day allanp...@gmail.com wrote: I presume you'd be happy for Deja Dup to become a GNOME Control Center panel? Depends on what you mean. I'm happy for Deja Dup to be shown as a panel in the control center. But it sounds like you're asking about actually putting it in the control center git tree? I guess I don't see the point. * I'd like to continue to support GTK-but-not-GNOME platforms (why not?) even if only as second-class citizens. So I'll probably add a preference dialog that simply wraps the deja-dup control panel for such cases. Having the panel be out-of-trunk makes that unnecessarily hard. It makes it harder, I guess. Whether it is unnecessary depends on your point of view. ;) * I assume the rest of deja-dup would be a separate module, so now it would be split across modules, losing the ability to share translations or logic. I'd have to write a library to share some of the logic bits. So that would be more work. * The only reason to be in tree that I can see is that g-c-c plans to drop the API for panels? But that is a separate thread. And what a thread it is... If Deja Dup is accepted, we'll need to work together and GNOME contributors (developers, designers, bug reporters and triagers, translators, documentors, etc) will want to contribute to Deja Dup. How will they do that? My intent is to achieve high levels of collaboration. Great to hear! GNOME has a lot to offer; we could achieve great things together! I have lots of ideas about how the GNOME community and LP projects can have tighter integration. I can defend why LP works for me, but that's not entirely the point here I feel. It could be so easy to collaborate! We could mirror bzr trunk in git, grant permissions to bzr trunk to an automatically sync'd group on LP, grant permissions to the translation web UI+trunk to the GNOME translation team. I could move my mailing list. I like to think the project already works well with GNOME designers (you and I have done a review before). Etc. Moving the mailing list would be helpful for design collaboration, I think. I'm kinda happy to follow your current LP list, but other designers might not be. So the big question to GNOME is how much do ya'll want to avoid the extra step of such collaboration for Features you consider part of your core? Is that a hard-blocker? Who gets to decide if it is? I'm theoretically open to moving infrastructure, pending a weighing of benefits. But I'm also curious if GNOME is even theoretically open to me not moving. It's the release team who decide in the final instance. (So see Fred and Olav's messages. :) ) My personal view is that we should be flexible, provided that we can find a way to effectively work together. Would you be willing to use GNOME Bugzilla? See my other message on the branding question - this isn't necessarily a problem. I'm just interested to hear your thoughts on how Deja Dup will be branding itself as a standalone application. I had envisioned the same way as a non-standalone app. It would appear as Backup to the user. Either as a standalone preference dialog or control center panel. But I've been thinking it needs to show its brand name at least once (I currently show it in the welcome screen). That way users know what they are getting. Now if your question is really about what that brand is (GNOME Backup vs Deja Dup) that's a different issue that I'm just now guessing you meant? I don't feel strongly on the name presented to users. I'm open to feedback here. It could maybe even be presented differently if deja-dup is a standalone app vs a panel? Thanks, that's really useful. This is somewhat new territory for GNOME, so it's nice to know we have the flexibility to work things out. 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: GNOME Feature Proposal: Backup
On Fri, May 13, 2011 at 11:40:28AM +0200, Frederic Peters wrote: We do have a few exceptions at the moment, mostly in cross desktop services stuff, of core components hosted elsewhere, from a quick look at jhbuild core moduleset we have NetworkManager and accountsservice on freedesktop, PackageKit is hosted on gitorious, PulseAudio on 0pointer.de. Should we reach out to them? Or should we have another policy for those kind of modules? I consider them external. The important bits of NetworkManager are on GNOME infra btw. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 12:28, Allan Day allanp...@gmail.com wrote: Would you be willing to use GNOME Bugzilla? That specifically would be the hardest part of an infrastructure move. Some important downstreams (Ubuntu and flavors) and my sister project Duplicity are all in LP. So it's very easy to share bugs and triaging work there. Plus since I'm an Ubuntu developer in my day job, it's my normal workflow. So there's good technical collaboration reasons why I value LP for bugs as well as the more squishy comfort reason. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Michael Terry wrote: On 13 May 2011 12:28, Allan Day allanp...@gmail.com wrote: Would you be willing to use GNOME Bugzilla? That specifically would be the hardest part of an infrastructure move. Some important downstreams (Ubuntu and flavors) and my sister project Duplicity are all in LP. So it's very easy to share bugs and triaging work there. Plus since I'm an Ubuntu developer in my day job, it's my normal workflow. So there's good technical collaboration reasons why I value LP for bugs as well as the more squishy comfort reason. There are good reasons for wanting to have Deja Dup on GNOME Bugzilla, I think. I can imagine myself wanting to CC other GNOME contributors on Deja Dup bugs. I can also imagine bugs being punted between Deja Dup and other GNOME modules. Plus there's the whole release planning and GNOME QA effort to consider. Don't forget that there's a high chance that people will fix Deja Dup bugs for you if you're on GNOME Bugzilla. :) 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 GNOME Feature Proposal: Backup]
least. it has a painful transition, but it's working pretty fine for now. Oh really? What is your criteria of success? ___ 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 12:36:41PM +0100, Sergey Udaltsov wrote: least. it has a painful transition, but it's working pretty fine for now. Oh really? What is your criteria of success? Let's not go into this type of yes/no discussion any further. Seems continuing this discussion on desktop-devel-list is not going to change anyones mind at this stage. -- Regards, Olav ___ 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 GNOME Feature Proposal: Backup]
Right. All I asked from the start is documenting the current vision. Seems continuing this discussion on desktop-devel-list is not going to change anyones mind ___ 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 10:28:25AM +0100, Sergey Udaltsov wrote: Distribution differences are something to be avoided, not encouraged. It is not for gnome to decide. See the messages from Ross. Differences are inevitable. Let's embrace differences, let's minimise patches. Let's be friendly to downstream. Anyway, since distros are patching in their capplets - gnome FAILED the main goal - to define the final experience. And that failure was unevitable. So closing apis is just a form of avoiding responsibility for the failure. I don't see this happening. Are you talking about GNOME 3 or GNOME 2.x here? The whole design part is new. My view is that we're way more friendly to do things for downstream. Instead of letting people patch things themselves, we'll look at their needs and see where we can add it. Calling it a failure is premature. I dislike that I have a Mandriva control center. It is unevitable with the current approach umho. But we're changing our approach. We want people to suggest their needs at GNOME, then we'll see how we can solve their issues. -- Regards, Olav ___ 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 GNOME Feature Proposal: Backup]
On 2011-05-13 at 12:36, Sergey Udaltsov wrote: least. it has a painful transition, but it's working pretty fine for now. Oh really? What is your criteria of success? the most important release of the past 5 years of Gnome being successful? what is your metric of success for the previous model? contributions from downstream? overall quality of the external capplets? ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ 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 GNOME Feature Proposal: Backup]
Il giorno ven, 13/05/2011 alle 12.16 +0200, Olav Vitters ha scritto: The control-center maintainers made a quick API for GNOME 3.0 only. Saying the removal is censorship? Of course not a real world censorship, but something that resembles it. System Settings is a place that can be useful to third parties and you are arbitrarily choosing to lock it. You are preventing someone to do something, not because it's not (technically) possible, but because you (politically) don't want. What about all the options that are not in the GNOME 3.0 control center? Good question. For example all Power settings options currently available only through dconf-editor or gsettings... With current approach (no extra panels) you are going to kill the free enterprise. We have the official Power panel with few options and no one is allowed to provide an additional Extra Power releasing a gnome-control-center-extra-power-0.4-0.tar.gz package with controls for hidden options. It seems the only allowed (but discouraged, if you don't plan to put your stuff upstream) way is to fully patch gnome-control-center module. This approach is only feasible if you are a distro maker. We have a framework (i.e. system settings), but we don't allow people to provide their own additions and improvements in a simple way. More, we dislike their additions, because they don't fit in our desktop vision. DISCLAIMER: I'm not saying an Extra Power is an actual improvement for anyone or it should exist. Also I know gnome-tweak-tool is available. The previous was just an example, not actual software. What about our license? This was never an issue to me. My concerns are about policies. What about a maintainers decision and the goal of a project? I've asked a similar (unanswered) question before: who is in charge to settle those _technical_ and _political_ sides of GNOME Desktop development? Of course maintainers choose for their own modules. But IMHO this issue is more related to GNOME as DE project then gnome-control-center as a single module, 'cause it involves the core nature of GNOME Desktop as place for third parts to develop their own solution. Your definition of censorship applies to everything that a maintainer does. Not applying a patch or implementing a feature would also be censorship. Yes and no, IMHO there is a difference between select the patch/feature to apply/implement and force people to collaborate upstream See what's happening in main thread about deja-dup inclusion: now Michael have to choose between kill his own beloved project and merge with gnome-c-c or keep its identity and let it survive in GNOME as second class citizen. If we really want to promote this kind of policy (I've another emotional word for it: cannibalization), well, sorry, I've to strongly disagree. I prefer to have a little confusional System Settings dialog, in exchange for cross-fertilisation between GNOME and external stuff. GNOME is now way more design orientated; could also call it decisions.. or censorship. The latter has a strong emotional impression. I'd rather have people talk about the goal of GNOME without too much emotional implications. Unfortunately we are not speaking about technical issues :( So it's not simple to discuss putting away our own convictions on how GNOME and FLOSS should be. Too much emotions only leads to heated arguments and people not listening to eachother anymore. To be honest, I feel nobody replied on my own not-so-emotional points and questions, such as: * gnome-shell is extensions friendly; if we want a full control on end users experience, then we should remove them too; * we are going to make gnome-c-c a closed place for non-upstream and non-distro vendors, and IMHO this is a failure from a market point of view (why should third parties choose to invest in a dictatorial software?) * should GNOME be a final product or a resource for distro? a resource to customize, of course * are we so much afraid about customizations? are customization the Evil? -- ok, this was a bonus and sarcastic question :) Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Le vendredi 13 mai 2011 à 12:25 +0200, Michael Terry a écrit : On 13 May 2011 11:53, Gendre Sebastien ko...@romandie.com wrote: I'm agree with Luca: It would be better if split Déjà Dup with Gnome Backup. Also, we can have: - Gnome Backup as a G-C-C panel for Gnome Desktop. - Déjà Dup as a GTK+ Application for non-Gnome Desktop, ex for XFCE. One minor point about this: Deja Dup is GPL-3+. G-C-C is GPL-2+. -mt So, we need to create a new panel Gnome-Backup from zero, Panel that an use different backend like Déjà-Dup/Duplicity, BTRFS-Snapshot, etc. Backend can be in GPLv2+, no? Regards -- Gendre Sebastien ko...@romandie.com 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 GNOME Feature Proposal: Backup]
I don't see this happening. Are you talking about GNOME 3 or GNOME 2.x here? Gnome3, since gnome2 did not have the goal to define the final experience. And it was more open. The whole design part is new. My view is that we're way more friendly to do things for downstream. What kind of friendship is that?? You force downstream to do things upstream or suffer patching. You are taking the freedom to extend comfortably - the freedom that existed in gnome2. Friendship? Calling it a failure is premature. It is a failure from the start, because distros will be patching. They will define the final experience, not gnome. End-users almost never use vanilla gnome. They never will, distros will patch. But we're changing our approach. We want people to suggest their needs at GNOME, then we'll see how we can solve their issues. That's what you want. Do distros want the same? Do 3rd party appdevs want the same? Or do you just not care? 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 03:26:00PM +0100, Sergey Udaltsov wrote: That's what you want. Do distros want the same? Do 3rd party appdevs want the same? Or do you just not care? To all: This thread is getting too heated and personal for me to feel comfortable to try and find ways to continue. So I'll just stop. -- Regards, Olav ___ 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 GNOME Feature Proposal: Backup]
Le vendredi 13 mai 2011 à 15:49 +0100, Sergey Udaltsov a écrit : If that is a bad excuse for the heated discussion, at least that explains why it is hot. If I summarize the choice of Gnome Dev about panel by an exemple: The choice of operating system to boot at startup. They don't want to see a panel for manage Grub, a panel to manage Lilo, a panel to manage EFI, etc. But they want to see a generic panel make directly in Gnome Control Center and different back-end for each technologie. All that to have only one UI for all usage and don't break the logical of all Gnome UI. And if we more summarize: They don't want to have too much of redundant panels for same features and with different UI logic. They prefer to have 1 panel with some different back-end. I don't think this way is bad. Regards. -- Gendre Sebastien ko...@romandie.com 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: GNOME Feature Proposal: Backup
On 13 May 2011 13:01, Allan Day allanp...@gmail.com wrote: There are good reasons for wanting to have Deja Dup on GNOME Bugzilla, I think. I can imagine myself wanting to CC other GNOME contributors on Deja Dup bugs. I can also imagine bugs being punted between Deja Dup and other GNOME modules. Plus there's the whole release planning and GNOME QA effort to consider. Don't forget that there's a high chance that people will fix Deja Dup bugs for you if you're on GNOME Bugzilla. :) (Note that I write here with love and without heat. I'm a GNOME developer and user and I want the world to be a better place.) I guess I was hoping more for collaboration than assimilation. :) Note that I am willing to, over time, train a new maintainer from within GNOME who could take over the project while I continue to contribute (which is more fun than maintaining). But I suspect there wouldn't be takers. If there would be, GNOME would likely already have a backup story or I would already see existing GNOME contributors to DD. You could call this the if you had invented Facebook you would be Facebook argument. I would also freely consult on how to fork part of DD or how to write a new backup program if GNOME really wanted to. Point is, I am largely just interested in the world not senselessly losing data (arguably the most preventable common point of pain with computers) regardless of who does it. So while I'm so willing to collaborate in that way, if I'm doing the work, I'd like to use the tools that make sense to me. Especially since I think it's so easy to collaborate between our tools. Granted, it's a bit harder than you'd ideally like. But I'm willing to meet you halfway (mailing list, mirrors, etc). Secondly, DD is already an app that has the stamp of approval for being featured in GNOME marketing last I checked. So GNOME can today talk about it's amazing backup story. So what does being a core module/Feature really buy here? (I mean, benefits above and beyond the goodness of being on GNOME infrastructure, which I could have without being a core module.) I see the following, but I may have missed something: * DD gets the slightly increased integration of being in the panel vs a window (really, not a large distinction in the grand scheme). * A formal agreement within GNOME that developers should be paying attention to the module. Though note that DD would love attention regardless of core status! :). * A bit of a social thing by declaring which camp DD is aligned with. Is it a policy requirement that Features be core modules? -mt ___ 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 GNOME Feature Proposal: Backup]
Le vendredi 13 mai 2011 à 17:28 +0200, Gendre Sebastien a écrit : And if we more summarize: They don't want to have too much of redundant panels for same features and with different UI logic. They prefer to have 1 panel with some different back-end. I don't think this way is bad. It is a very good approach, but I’m afraid forcing it fails the reality check. Until you reach a state where everything a downstream user might need is available in a correct way in the control center, it sounds better to let downstreams add a few more things to it rather than leaving them without a place for these extra settings. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- ___ 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 GNOME Feature Proposal: Backup]
Luca Ferretti wrote: snip Luca, I don't want to be rude, but you, Sergey, David, Emmanuele, and everyone else who has contributed multiple times to this thread in the past 24 hours have had your say, you've been heard. You're now just repeating yourself. Please stop polluting my in-box. As many others have said, this thread is going no-where, please just stop posting to it. 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 GNOME Feature Proposal: Backup]
2011/5/13 Luca Ferretti lferr...@gnome.org: Bonus question: are you sure this all work happens upstream can lead to better and faster solutions? I forgot a little example for this: 3 years ago I wrote a trivial patch to add a Search tool selector in Preferred Application preference tool. Start from [1] for reference. It was rejected, 'cause the upstream vision was: we want to provide a single search tool, no need to let people to choose their own. Today GNOME still lacks a search tool/feature :( [1] https://bugzilla.gnome.org/show_bug.cgi?id=491647 ___ 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 GNOME Feature Proposal: Backup]
On Fri, May 13, 2011 at 10:28, Gendre Sebastien ko...@romandie.com wrote: If I summarize the choice of Gnome Dev about panel by an exemple: The choice of operating system to boot at startup. They don't want to see a panel for manage Grub, a panel to manage Lilo, a panel to manage EFI, etc. But they want to see a generic panel make directly in Gnome Control Center and different back-end for each technologie. All that to have only one UI for all usage and don't break the logical of all Gnome UI. Please see David's 5th reply to this thread about what our plans for boot loader UI 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 GNOME Feature Proposal: Backup]
On Fri, 2011-05-13 at 18:44 +0200, Luca Ferretti wrote: 2011/5/13 Luca Ferretti lferr...@gnome.org: Bonus question: are you sure this all work happens upstream can lead to better and faster solutions? I forgot a little example for this: 3 years ago I wrote a trivial patch to add a Search tool selector in Preferred Application preference tool. Start from [1] for reference. It was rejected, 'cause the upstream vision was: we want to provide a single search tool, no need to let people to choose their own. Today GNOME still lacks a search tool/feature :( The correct way to behave then is to work on the search backends, not to complain here. There are plenty of hackish things that we'd like to implement, but they need to be implemented properly. /Bastien, kernel, udev and X.org contributor because fixing things properly is important ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi Michael, On Tue, May 10, 2011 at 9:49 AM, Michael Terry m...@mterry.name wrote: 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. So while I agree this new redesign looks better than the old app UI, you've caught us at a somewhat tricky time as we're trying to increase focus on quality in the core, and less on picking applications. Deja Dup could definitely qualify pretty easily as a Featured Application; see: https://live.gnome.org/TwoPointNinetyone/FeaturedApps A few concerns: 1) I'd like to see at least some discussion for how (if) this intersects with the already existing Finding and Reminding feature: https://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding 2) The external dependency set is pretty large =( It looks like duplicity would in turn pull in quite a few new modules. If you're serious about proposing this though, can you try fixing the jhbuild in the gnome-apps-3.2 moduleset to actually work? _librsyncmodule.c:26:22: fatal error: librsync.h: No such file or directory It looks like it's missing several things; the Fedora package at least depends on librsync, gnupg, python-boto. 3) If you're still planning to have this run outside of GNOME, are you going to keep around the application mode in some way? If so, maybe it makes sense to stick with that for this cycle, and we can make it a Featured App, and revisit deeper integration for 3.4? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On Fri, 2011-05-13 at 17:37 +0200, Michael Terry wrote: So what does being a core module/Feature really buy here? (I mean, benefits above and beyond the goodness of being on GNOME infrastructure, which I could have without being a core module.) I see the following, but I may have missed something: * DD gets the slightly increased integration of being in the panel vs a window (really, not a large distinction in the grand scheme). * A formal agreement within GNOME that developers should be paying attention to the module. Though note that DD would love attention regardless of core status! :). * A bit of a social thing by declaring which camp DD is aligned with. We get to make it the One True Way in the user help. Right now, we have a dozen or so pages about backups. And right now, they basically say Déjà Dup is cool. You should use it. But maybe you don't have it, so here's boring technical information. I'd rather the help could just discuss the GNOME backup system, but I can only do that if there's a GNOME backup system. -- Shaun ___ 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 GNOME Feature Proposal: Backup]
Il giorno Fri, 13/05/2011 alle 18.42 +0200, Dave Neary ha scritto: Please stop polluting my in-box. As many others have said, this thread is going no-where, please just stop posting to it. This could be true, we are discussing about ideas and visions and anyone has his strong option. But honestly this thread also helped to expose our own points of view and showed there was a lack of communication in our community (and maybe other issues). To be honest, nobody answered to some question I've answered or clarified some doubts. So, can you suggest me a better place to have a frank and official reply? 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 GNOME Feature Proposal: Backup]
Il giorno Sat, 14/05/2011 alle 01.11 +0200, Luca Ferretti ha scritto: Il giorno Fri, 13/05/2011 alle 18.42 +0200, Dave Neary ha scritto: Please stop polluting my in-box. As many others have said, this thread is going no-where, please just stop posting to it. This could be true, we are discussing about ideas and visions and anyone has his strong option. But honestly this thread also helped to expose our own points of view and showed there was a lack of communication in our community (and maybe other issues). To be honest, nobody answered to some question I've answered or I've asked of course ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 13 May 2011 21:50, Colin Walters walt...@verbum.org wrote: Deja Dup could definitely qualify pretty easily as a Featured Application; see: https://live.gnome.org/TwoPointNinetyone/FeaturedApps I had thought it was a Featured App already. When modulesets got redesigned during my previous proposal, I thought that was the outcome. But it's not in that list, true. Are Featured Apps still a thing in 3.2? I don't see the corresponding ThreePointOne page. A few concerns: 1) I'd like to see at least some discussion for how (if) this intersects with the already existing Finding and Reminding feature: https://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding I'd be interested in hearing from designers if there's any intersection here too. 2) The external dependency set is pretty large =( It looks like duplicity would in turn pull in quite a few new modules. If you're serious about proposing this though, can you try fixing the jhbuild in the gnome-apps-3.2 moduleset to actually work? _librsyncmodule.c:26:22: fatal error: librsync.h: No such file or directory It looks like it's missing several things; the Fedora package at least depends on librsync, gnupg, python-boto. Hrm. I do have a need to clean up the jhbuild sets. I also know that older modulesets should be pointing at the branches of DD, not trunk. I will fix that soon. 3) If you're still planning to have this run outside of GNOME, are you going to keep around the application mode in some way? If so, maybe it makes sense to stick with that for this cycle, and we can make it a Featured App, and revisit deeper integration for 3.4? I expect to allow building both a panel and a window versions of the preferences. That way, any distros that intend to follow through with re-adding the panel API can get a better experience if they want to. -mt ___ 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: GNOME Feature Proposal: Backup
On Wed, May 11, 2011 at 6:18 PM, Allan Day allanp...@gmail.com wrote: Michael Terry wrote: Hi, Allan. Thanks for your past and continuing help with design! :) Answers below. On 11 May 2011 11:33, Allan Day allanp...@gmail.com wrote: This looks like an improvement on the UI that you presented the last time you proposed Deja Dup. It could still be much better though. How would you feel about paring it down to something more minimal? Ideally, the UI should be limited to switching it and on/off, selecting the backup storage location, and giving an idea of status (a little 'hey, you're backups are fine!'). So specifically, you're talking about dropping: * Encryption toggle * Include/exclude * How long to keep backups * How often to back up I'm happy to have a discussion about what to do for each. That's great to hear. I'll follow that up with you. One question: I know that you had a discussion on the usability list about renaming Deja Dup. Would you be happy to remove the remaining references to Deja Dup in the UI and just call it Backup? The only remaining references are the one-time welcome screen and the help documentation. I'm not fully wedded to those, though I'm hesitant to remove all instances. I can think of a at least a couple reasons at least a one-time brand is useful: * Some branding (even only once) is useful here to reassure user it will read the backup data they made elsewhere. * The user can install it on non-GNOME and they need to know what app to search for. Since the moduleset reorganisation, we make a distinction between GNOME core and GNOME applications. If a module is part of the core it's supposed to be an integrated part of the user experience (as you've said you want to aim for - yay!), and it's supposed to use GNOME infrastructure. Looking at your proposal it seems that you are proposing Deja Dup for inclusion in the GNOME core. You also seem to want it to be developed on LP and for it to simultaneously exist as a standalone app, though. This opens up some potentially tricky issues: ... snip ... * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. Could you clarify this one a little? On first read it sounds like if Deja Dup becomes part of GNOME core, you aren't allowed to have it on any other platforms although I'm sure that's not at all what you meant. I'm struggling to pick up what you do mean though. Sorry for the potentially difficult questions! Thanks Sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Sam Thursfield wrote: ... snip ... * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. Could you clarify this one a little? On first read it sounds like if Deja Dup becomes part of GNOME core, you aren't allowed to have it on any other platforms although I'm sure that's not at all what you meant. I'm struggling to pick up what you do mean though. I put this too strongly. All I meant was that, if we present GNOME Backup as part of GNOME 3 (ie. GNOME core), it might look strange if it can be installed on non-GNOME systems. That wouldn't be an issue if Deja Dup were applying to be an application, I might add - it's fine having cross-platform GNOME apps. The issue is that it's potentially going to be a part of the core - the system - and there's maybe a discrepancy there with how we describe GNOME 3. I'm not saying this is a definite problem. It's just something to consider. 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: GNOME Feature Proposal: Backup
On 11 May 2011 19:18, Allan Day allanp...@gmail.com wrote: Looking at your proposal it seems that you are proposing Deja Dup for inclusion in the GNOME core. You also seem to want it to be developed on LP and for it to simultaneously exist as a standalone app, though. This opens up some potentially tricky issues: * What do we do about the infrastructure question? Core modules are supposed to be developed as a part of the wider project; that means that they use GNOME's infrastructure. * Can you technically achieve the level of integration that we're after if Deja Dup continues to exist as a standalone app? (This is a serious question - I don't know the answer.) * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. I'm coming into this interested less in questions framed as how can Deja Dup make GNOME better than as how can Deja Dup being part of GNOME make users' backup experience better. For example, I think of the infrastructure question in terms of whether there's a reason to believe switching to GNOME infrastructure will result in more or less maintenance work being done. And the branding question less in terms of will it be better for GNOME marketing than will it be better for users. -mt ___ 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: GNOME Feature Proposal: Backup
Michael Terry wrote: On 11 May 2011 19:18, Allan Day allanp...@gmail.com wrote: Looking at your proposal it seems that you are proposing Deja Dup for inclusion in the GNOME core. You also seem to want it to be developed on LP and for it to simultaneously exist as a standalone app, though. This opens up some potentially tricky issues: * What do we do about the infrastructure question? Core modules are supposed to be developed as a part of the wider project; that means that they use GNOME's infrastructure. * Can you technically achieve the level of integration that we're after if Deja Dup continues to exist as a standalone app? (This is a serious question - I don't know the answer.) * Branding - a part of the core should be branded as a part of GNOME 3, and I don't think we'd want GNOME's new backup facility to visibly exist outside of GNOME. I'm coming into this interested less in questions framed as how can Deja Dup make GNOME better than as how can Deja Dup being part of GNOME make users' backup experience better. I presume you'd be happy for Deja Dup to become a GNOME Control Center panel? For example, I think of the infrastructure question in terms of whether there's a reason to believe switching to GNOME infrastructure will result in more or less maintenance work being done. If Deja Dup is accepted, we'll need to work together and GNOME contributors (developers, designers, bug reporters and triagers, translators, documentors, etc) will want to contribute to Deja Dup. How will they do that? And the branding question less in terms of will it be better for GNOME marketing than will it be better for users. See my other message on the branding question - this isn't necessarily a problem. I'm just interested to hear your thoughts on how Deja Dup will be branding itself as a standalone application. Thanks, 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: GNOME Feature Proposal: Backup
On Thu, May 12, 2011 at 03:34, Allan Day allanp...@gmail.com wrote: That wouldn't be an issue if Deja Dup were applying to be an application There is no process of applying to be a GNOME application except perhaps requesting infrastructure hosting--but that's available to anyone, really. ___ 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 GNOME Feature Proposal: Backup]
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. Technically, if the architecture only allows extension through patching (instead of extension points), it means the architecture is closed (that must be a highly offensive statement, if we're talking about free software). Also, that is a very effective way to alienate 3rd parties (app developers, distromakers). I suspect, that attitude in gnome possibly affected Canonical decision to drop gnome 3. I would not be surprised if other distros follow that example. First _unfriendly_ move from GNOME side: distros have to either patch g-c-c to introduce distro-specific capplets (maintaining patches is not the same thing as maintaining separate modules using relatively stable APIs) or invent their own settings mgmt frameworks. If some distro chooses the 2nd way - why stop? Next step - move all things to shiny new distro-specific config UI, then - replace gnome-shell. Good bye, GNOME3! GNOME is not an OS. GNOME is not a distribution. GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions - it is them who define the _final_ user experience. Do we all agree that GNOME should be distribution-friendly, that GNOME should trust distributions, make their life reasonably comfortable? So let them put the configuration for the drivers, for the system services, if they like, etc into g-c-c. Let them = make it reasonably comfortable = use APIs, not patching. If we do not trust distributions ... we have to change a lot of things in GNOME, starting from the first letter of the name (back at the days of GNOME 1 G was for GNU) All those rants aside, let me ask one question: is this APIlessness considered as a temporary measure (I know, gnome 3 is currently highly undocumented - at least I did not see g-c-c 3 UI guidelines) for some transitional period or is it a policy that is planned to last in foreseeble future of gnome3? 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]
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 GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 14:45, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Technically, if the architecture only allows extension through patching (instead of extension points), it means the architecture is closed (that must be a highly offensive statement, if we're talking about free software). So every piece of free software that hasn't yet implemented extension points is offensive to free software, according to you? Doesn't that seem like a somewhat extreme position? Also, that is a very effective way to alienate 3rd parties (app developers, distromakers). Not really, no. UI's that users don't want to use because they are confusing alienates 3rd parties because, well, we don't have any users. Why don't we get some users and then worry about alienating developers by encouraging good design? I suspect, that attitude in gnome possibly affected Canonical decision to drop gnome 3. This is completely fabricated speculation which is, in fact, not true. Please refrain from spreading false information; that doesn't help anyone. distros have to either patch g-c-c to introduce distro-specific capplets (maintaining patches is not the same thing as maintaining separate modules using relatively stable APIs) We don't want 3rd parties putting things in g-c-c--that's all we're saying. But it's free software; they can if they want to, of course. GNOME is not an OS. But it could be. GNOME is not a distribution. Right. GNOME is a core desktop (desktop building toolkit, if you like)/ We want it to be more. All those rants aside, let me ask one question: is this APIlessness considered as a temporary measure (I know, gnome 3 is currently highly undocumented - at least I did not see g-c-c 3 UI guidelines) for some transitional period or is it a policy that is planned to last in foreseeble future of gnome3? Couldn't you have asked before ranting? ___ 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 GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 3:45 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions No, GNOME is not a supermarket. It's not a place where you go to get your technology so you can put it together in your own sandbox. This might be inconvenient for downstreams (including my employer) but it is what it is. The fact that you _can_ (easily) fork GNOME just happens to be a side-effect of the license. It's not the major point of the project. David ___ 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 GNOME Feature Proposal: Backup]
No, GNOME is not a supermarket. It's not a place where you go to get your technology so you can put it together in your own sandbox. This might be inconvenient for downstreams (including my employer) but it is what it is. The fact that you _can_ (easily) fork GNOME just happens to be a side-effect of the license. It's not the major point of the project. My whole point was that in the ideal world GNOME could be extensible enough so that no _forking_ would be necessary. Extension modules, not patches. That would be not a side effect of the license but the fundamental feature of the architecture. Do you see the difference? Well, anyway, there are other people who drive the project. I just think it would be fair if GNOME could make some official statement on extensibility policy. That question was already asked in that thread, before my intervention. That probably is worth a page on live.gnome.org 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 GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 4:39 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: My whole point was that in the ideal world GNOME could be extensible enough so that no _forking_ would be necessary. Extension modules, not patches. That would be not a side effect of the license but the fundamental feature of the architecture. Do you see the difference? Yes. I also think we tried that with GNOME 2 and failed. I mean, look at GNOME 2's control center - on all distros, it's a royal mess of random crap from either GNOME, the distro or 3rd party app written by a kid in a basement. With GNOME 3.2, we will have a simpler control center (since the extension mechanism is going away) but it will be _awesome_. Sure, the GNOME 3.x control center doesn't do all you need yet but the point really is that we're engaging the current providers of control center items to _work_ with GNOME. In particular, it means working with designers. And in some cases (e.g. boot loader) the solution is sometimes to not have a control center item... but maybe put the feature in the system restart dialog instead. The other bonus thing is that GNOME will _include_ the feature instead of each and every distro doing their own thing. So in the long run everybody wins [1]. Extension- and plug-in systems is often the symptom of a disease. Especially in young evolving software such as e.g. GNOME 3.x. Don't succumb to it. Just say no. David [1] : Except of course if some downstreams do development in their own fucking sandbox.. no, this is not a cheap jab at Canonical.. it includes e.g. Red Hat too. Or SUSE. Trust me when I say that the RH desktop team and the RH team doing the system-config-* tools have fought _a lot_ about these issues. ___ 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 GNOME Feature Proposal: Backup]
Extension- and plug-in systems is often the symptom of a disease. How would you distinguish...? [1] : Except of course if some downstreams do development in their own fucking sandbox.. no, this is not a cheap jab at Canonical.. it includes e.g. Red Hat too. Or SUSE. Thank you, that is very interesting and insightful info. The question is - could (or would) GNOME do something to avoid that situation with distros? g-c-c could be for linux what system preferences are for macos or control panel for windows - configuring every aspect of OS except configs of desktop apps (but including system configs, server apps config etc). Well, if gnome does not want it, let it be so. I am just kindly asking to put together some kind of policy document about all those things. Is that a reasonable and constructive request? Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
2011/5/12 Allan Day allanp...@gmail.com: I'm coming into this interested less in questions framed as how can Deja Dup make GNOME better than as how can Deja Dup being part of GNOME make users' backup experience better. I presume you'd be happy for Deja Dup to become a GNOME Control Center panel? But, following statements from g-c-c maintainers and designers, if/when deja-dup will become an official GNOME System Settings panel, then there will no more Deja Dup, but simply a generic GNOME Backup Service (remember? no brand for core stuff). Also I suppose you'll also need to split deja^W gnome-backup in two modules: the panel UI in gnome-control-center and the message tray icon (and daemon) in gnome-system-settings (see external media handling feature extracted from nautilus in 2.3x - 3.0 transition). ___ 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 GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 5:23 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Extension- and plug-in systems is often the symptom of a disease. How would you distinguish...? I don't know. It's typically a highly subjective thing. Mostly it comes down to what most people refer to as good taste vs bad taste. I don't know. [1] : Except of course if some downstreams do development in their own fucking sandbox.. no, this is not a cheap jab at Canonical.. it includes e.g. Red Hat too. Or SUSE. Thank you, that is very interesting and insightful info. The question is - could (or would) GNOME do something to avoid that situation with distros? Not showing 3rd party panels is one path forward. And I think it's the right one. If all distros just patch in their own panels, maybe we need to use a bigger stick to make them work upstream. g-c-c could be for linux what system preferences are for macos or control panel for windows - configuring every aspect of OS except configs of desktop apps (but including system configs, server apps config etc). But that way you end up with useless things like a Java Control Panel or httpd Control Panel [1] and other non-sense that you see on Windows (and OS X for that matter - it's just that people don't install much 3rd party crap there). [1] : for example, system-config-httpd in Fedora is nothing more than an fancy editor for /etc/httpd/conf/httpd.conf - it's a completely inappropriate app because if you know what httpd is, you really don't want to click GUI buttons - you want to edit the config file with vi(1) or whatever your editor of choice is. Same goes for a lot of other distro-specific config tools created because we need a GUI without really thinking whether it was a good idea. /rant Well, if gnome does not want it, let it be so. I am just kindly asking to put together some kind of policy document about all those things. Is that a reasonable and constructive request? Not sure we need to be all lawyerish about it and write policy documents and whatnot - I'd rather people spend time on writing awesome code and doing awesome designs. All in the same sandbox :-) And, FWIW, I'm just expressing my personal opinion about GNOME and nothing I'm saying here is authoritative. It could be that the gnome-control-center maintainers and others have other views about it. David ___ 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 GNOME Feature Proposal: Backup]
Il giorno gio, 12/05/2011 alle 20.45 +0100, Sergey Udaltsov ha scritto: GNOME is not an OS. GNOME is not a distribution. GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions - it is them who define the _final_ user experience. Do we all agree that GNOME should be distribution-friendly, that GNOME should trust distributions, make their life reasonably comfortable? I totally agree, IMHO GNOME is a base to allow distributors, vendors and third parts to build up and extend their own user experience and services and fight on free market. No competition means stagnation. But it seems by now we are a small minority :-| All those rants aside, let me ask one question: is this APIlessness considered as a temporary measure (I know, gnome 3 is currently highly undocumented - at least I did not see g-c-c 3 UI guidelines) for some transitional period or is it a policy that is planned to last in foreseeble future of gnome3? May I add: who is in charge to settle those _technical_ and _political_ sides of GNOME Desktop development? ;-) 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 GNOME Feature Proposal: Backup]
I don't know. It's typically a highly subjective thing. Mostly it comes down to what most people refer to as good taste vs bad taste. I don't know. Fair enough. Not showing 3rd party panels is one path forward. And I think it's the right one. If all distros just patch in their own panels, maybe we need to use a bigger stick to make them work upstream. Well, their own panels might control things that are not related to the desktop as such. I do not think anyone in gnome would welcome those things upstream... But that way you end up with useless things like a Java Control Panel or httpd Control Panel [1] and other non-sense that you see on Windows (and OS X for that matter - it's just that people don't install much 3rd party crap there). Right, httpd control panel is basically one example of what redhat's system-config-* tools are doing. an fancy editor for /etc/httpd/conf/httpd.conf - it's a completely inappropriate app because if you know what httpd is, you really don't want to click GUI buttons - you want to edit the config file with vi(1) or whatever your editor of choice is. Same goes for a lot of other distro-specific config tools created because we need a GUI without really thinking whether it was a good idea. /rant Err... Personally I always thought that the area where IIS was way ahead of httpd is the GUI configuration tools nicely integrated into system configuration GUIs. Not sure we need to be all lawyerish about it and write policy documents and whatnot - I'd rather people spend time on writing awesome code and doing awesome designs. All in the same sandbox :-) Well, it is not about law - it would just indicate that people should not even bother using temporary public APIs that might occationally (for some tactical reason) be provided. That would explain that the only way to keep long-term health relations with GNOME as upstream is do to THESE things and not to do THOSE things. Helpful strategy hints. And, FWIW, I'm just expressing my personal opinion about GNOME and nothing I'm saying here is authoritative. It could be that the gnome-control-center maintainers and others have other views about it. Sure. But according to this thread, your opinion is very similar to the ideas expressed by many others, including g-c-c drivers. Thank you for explaining things. ___ 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 GNOME Feature Proposal: Backup]
I totally agree, IMHO GNOME is a base to allow distributors, vendors and third parts to build up and extend their own user experience and services and fight on free market. No competition means stagnation. Yes, very true. GNOME wants to dictate some policies. Fair play, because we own the code. But that dictate may kill gnome publicly - if distros would not want to be dictated. Back into the history, X11 provided mechanism, not policy. GNOME enforces policies. Fine, but let's not go too far with this dictate. And anyway, even if we dictate policies - at least we should have courtesy to put them in words, I guess. But it seems by now we are a small minority :-| Seem so. May I add: who is in charge to settle those _technical_ and _political_ sides of GNOME Desktop development? ;-) Very good question, actually. ___ 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 GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 16:51, Sergey Udaltsov sergey.udalt...@gmail.com wrote: I totally agree, IMHO GNOME is a base to allow distributors, vendors and third parts to build up and extend their own user experience and services and fight on free market. No competition means stagnation. Yes, very true. GNOME wants to dictate some policies. Fair play, because we own the code. But that dictate may kill gnome publicly - if distros would not want to be dictated. Back into the history, X11 provided mechanism, not policy. GNOME enforces policies. Fine, but let's not go too far with this dictate. And anyway, even if we dictate policies - at least we should have courtesy to put them in words, I guess. We're not dictating anything; we're just making an awesome OS, the way we envision, period. Dictating is what Mozilla tried to pull with their trademark policy. We aren't doing that. And I can't see us ever trying to do that, either. ___ 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 GNOME Feature Proposal: Backup]
We're not dictating anything; we're just making an awesome OS, the way we envision, period. Wait a sec. It was said (here and on IRC) that g-c-c wants to include only polished panels to g-c-c. Only panels that gnome UI specialists are happy with. It is a form of dictate - or I do not know what dictate is. Or did I misunderstand some statements? In a way, even HIG itself is a dictate - a relatively weak form of it (but at least put into the document, which is the best thing about HIG!) ___ 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 GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 5:58 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: We're not dictating anything; we're just making an awesome OS, the way we envision, period. Wait a sec. It was said (here and on IRC) that g-c-c wants to include only polished panels to g-c-c. Only panels that gnome UI specialists are happy with. It is a form of dictate - or I do not know what dictate is. Or did I misunderstand some statements? In a way, even HIG itself is a dictate - a relatively weak form of it (but at least put into the document, which is the best thing about HIG!) I think this argument has reached the point of absurdity. ___ 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 GNOME Feature Proposal: Backup]
Il giorno gio, 12/05/2011 alle 16.51 -0400, David Zeuthen ha scritto: Yes. I also think we tried that with GNOME 2 and failed. I mean, look at GNOME 2's control center - on all distros, it's a royal mess of random crap from either GNOME, the distro or 3rd party app written by a kid in a basement. So? Why this should be a failure? If so you should say the same for Applications menu: it provides stuff from GNOME, stuff from distributor and stuff you install using a third part repository. And sometimes people have installed many web applications and their Internet menu was bigger the 10 items (you know, this was not approved in GNOME2 design) :P And I've to admit: I've install Virtualbox even though it could break the polish of my GNOME3 experience. Please do not mix the feature (allow third part System Settings panel) with misuse (a specific System Setting panel is badly designed and its controls should be placed somewhere else). ___ 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 GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 5:47 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: an fancy editor for /etc/httpd/conf/httpd.conf - it's a completely inappropriate app because if you know what httpd is, you really don't want to click GUI buttons - you want to edit the config file with vi(1) or whatever your editor of choice is. Same goes for a lot of other distro-specific config tools created because we need a GUI without really thinking whether it was a good idea. /rant Err... Personally I always thought that the area where IIS was way ahead of httpd is the GUI configuration tools nicely integrated into system configuration GUIs. Didn't IIS actually add a configuration file after strong demands from administrator? I don't know, it's not important. Now, whether a HTTP server needs config UI or not... nothing prevents anyone from writing an app that does that... It just won't be shown in the System Settings, that's all. Which I actually think makes sense. I actually regard a stock HTTP server like Apache (or even an application server such as e.g. Tomcat) more as an application, not an OS component. And I think, these days, you'd maybe want to write the configuration UI for a webserver using HTML5 and JS anyway. I don't know. That said, it could be that some HTTP server configuration could appear in the Sharing panel, see http://live.gnome.org/ThreePointOne/Features/Sharing - for example, to share your public folder via HTTP and exposing a bookmark via mDNS so it shows up in browsers on the LAN that supports this (for example, Safari and Epiphany I think). That would be handy. Either way, I think this is completely orthogonal to the discussion on whether such a panel makes sense. I'm just mentioning this to explain how GNOME should, no wait, MUST, be driven by design. Not some misguided feature-for-feature parity thing or some PHB-directive saying everything needs a GUI. In there lies madness. David ___ 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 GNOME Feature Proposal: Backup]
On 12 May 2011 23:42, Luca Ferretti lferr...@gnome.org wrote: Il giorno gio, 12/05/2011 alle 20.45 +0100, Sergey Udaltsov ha scritto: GNOME is not an OS. GNOME is not a distribution. GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions - it is them who define the _final_ user experience. Do we all agree that GNOME should be distribution-friendly, that GNOME should trust distributions, make their life reasonably comfortable? I totally agree, IMHO GNOME is a base to allow distributors, vendors and third parts to build up and extend their own user experience and services and fight on free market. No competition means stagnation. But it seems by now we are a small minority :-| Or are we a silent majority? It seems we don't have enough information to say either way. ___ 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 GNOME Feature Proposal: Backup]
Il giorno gio, 12/05/2011 alle 18.14 -0400, David Zeuthen ha scritto: So? Why this should be a failure? Because the premise of System Settings in GNOME 3 is, surprisingly, to change your system settings or personalize the experience. So, are there no system settings or personalizations other then the ones provided by GNOME? 6.x billions of people and only ten (or so) settings panel? We should strive to make this as easy as possible and having 20 panels such as Java Settings or HTTPD Control or even Firewall is something that gets in the way. So if we allowed 3rd party panels, it would be a failure because trusting that people won't write broken panels like the ones mentioned above is, unfortunately, very naive. Wait: first, it's GNOME3, not GNOME2, you can't provide a new panel simply adding a .desktop file with proper keys. You have to develop it using proper API. This is a first barrier for broken stuff. Second: are we a censorship? are we fighting against the ugly? are all non-gnome developers odd and stupid? It seems your starting point is: everybody's wrong, but not GNOME people. I feel it really offensive and counterproductive for GNOME project itself. ___ 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 GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 6:34 PM, Luca Ferretti lferr...@gnome.org wrote: Il giorno gio, 12/05/2011 alle 18.14 -0400, David Zeuthen ha scritto: So? Why this should be a failure? Because the premise of System Settings in GNOME 3 is, surprisingly, to change your system settings or personalize the experience. So, are there no system settings or personalizations other then the ones provided by GNOME? 6.x billions of people and only ten (or so) settings panel? We should strive to make this as easy as possible and having 20 panels such as Java Settings or HTTPD Control or even Firewall is something that gets in the way. So if we allowed 3rd party panels, it would be a failure because trusting that people won't write broken panels like the ones mentioned above is, unfortunately, very naive. Wait: first, it's GNOME3, not GNOME2, you can't provide a new panel simply adding a .desktop file with proper keys. You have to develop it using proper API. This is a first barrier for broken stuff. Second: are we a censorship? are we fighting against the ugly? are all non-gnome developers odd and stupid? It seems your starting point is: everybody's wrong, but not GNOME people. I feel it really offensive and counterproductive for GNOME project itself. Speaking of offensive, suggesting that GNOME is a censorship is pretty offensive. Not to mention insulting. I'm not going to have a conversation with you like this. Please keep it real. Thanks, David ___ 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 GNOME Feature Proposal: Backup]
Hi, On Thu, May 12, 2011 at 6:13 PM, Robert Ancell robert.anc...@gmail.com wrote: On 12 May 2011 23:42, Luca Ferretti lferr...@gnome.org wrote: Il giorno gio, 12/05/2011 alle 20.45 +0100, Sergey Udaltsov ha scritto: GNOME is not an OS. GNOME is not a distribution. GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions - it is them who define the _final_ user experience. Do we all agree that GNOME should be distribution-friendly, that GNOME should trust distributions, make their life reasonably comfortable? I totally agree, IMHO GNOME is a base to allow distributors, vendors and third parts to build up and extend their own user experience and services and fight on free market. No competition means stagnation. But it seems by now we are a small minority :-| Or are we a silent majority? It seems we don't have enough information to say either way. Either way, it isn't what GNOME is about or really has ever been about. Please read: http://blog.fishsoup.net/2011/03/11/what-does-the-user-see/ There isn't any point in spending time to design, plan, craft a user experience for it to be just bits of putty in another's hands. That's an absurd premise. Very simply, we aim for external competition, internal cooperation. Not the other way around. Thanks, Jon ___ 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 GNOME Feature Proposal: Backup]
On Thu, May 12, 2011 at 6:34 PM, Luca Ferretti lferr...@gnome.org wrote: We should strive to make this as easy as possible and having 20 panels such as Java Settings or HTTPD Control or even Firewall is something that gets in the way. So if we allowed 3rd party panels, it would be a failure because trusting that people won't write broken panels like the ones mentioned above is, unfortunately, very naive. Wait: first, it's GNOME3, not GNOME2, you can't provide a new panel simply adding a .desktop file with proper keys. You have to develop it using proper API. This is a first barrier for broken stuff. Second: are we a censorship? are we fighting against the ugly? are all non-gnome developers odd and stupid? It seems your starting point is: everybody's wrong, but not GNOME people. I feel it really offensive and counterproductive for GNOME project itself. This is really starting to drift into a highly emotional and non-productive direction. Not allowing random third parties to put their pet projects preferences into the very core of GNOME is very different from censorship. It is maintaining meaningful boundaries between what is GNOME and what is not. ___ 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 GNOME Feature Proposal: Backup]
On 12 May 2011 20:45, Sergey Udaltsov sergey.udalt...@gmail.com wrote: GNOME is not an OS. GNOME is not a distribution. GNOME is a core desktop (desktop building toolkit, if you like) that is used by distributions - it is them who define the _final_ user experience. That may be what you think but, since some time now, it's not what most active core GNOME contributors are aiming to. Yes, GNOME should be an OS. Yes, GNOME should define the final user experience. Why? Because doing software without *well* defined boundaries is a technical maintenance nightmare (especially in a free software project with the usual lack of human resources) and will never yield the kind of cohesive, fluid experience that IMO constitutes the GNOME vision. Rui ___ 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 GNOME Feature Proposal: Backup]
Il giorno gio, 12/05/2011 alle 19.12 -0400, Matthias Clasen ha scritto: This is really starting to drift into a highly emotional and non-productive direction. I'm not emotional, just a little overemphatic :) Not allowing random third parties to put their pet projects preferences into the very core of GNOME is very different from censorship. It is maintaining meaningful boundaries between what is GNOME and what is not. Then, as I said on another reply, why are gnome-shell extensions allowed to change gnome-shell so deeply[1]? More, why is gnome-shell providing support to extensions? BTW pet project... IMHO pet is something that plays down the merits, isn't it? [1] see http://intgat.tigress.co.uk/rmy/extensions/index.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
