Re: GNOME Feature Proposal: Backup
Hi, Michael Terry wrote: > My plans have always been aimed at personal data only, with any > support for whole-system backup as a nice bonus. There are technical > issues there like "if you hit a file the user doesn't have read > support for, are you going to prompt for the root password every > time?" FWIW, this is exactly the use-case I'm missing. I would like to copy my personal data to an external hard drive, remote server or cloud storage service, so that if my hard drive goes boom, I can get my settings, documents, photos, etc back after installing a new distribution on a new system. I'm not that bothered about a full system recovery for a GNOME back-up tool. So I applaud your focus :) 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 07:32 +0200, Michael Terry wrote: > So as the Deja Dup maintainer, life will go on when you drop support. > Worst case, I can just make the panel a dialog. > > But dropping the existing API feels like a frustrating bait and > switch. It was not clear (at least to me) that this was your > intentional all along, so myself and others made plans and put effort > into making panels. > while I'm not sure making the API private is the best idea, I really understand the reasons behind that decision, which is to not allow for a control-center crowded with lots of crazy panels, specific to applications. But backup is indeed something that makes a lot of sense as a System Settings panel, so I think it could probably be integrated into gnome-control-center itself. So, what are the dependencies the c-c panel in Deja Dup has? So, getting some design for this would be a good thing, so that we can start integrating it into the control center itself. Also, another solution might be to keep the g-c-c API public, but have a whitelist, so that we just list there the panels that we bless and that will be loaded in the g-c-c shell. Others would just be ignored, and so distributions can choose to add the panels they want to the whitelist. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On Tue, 2011-05-10 at 20:51 +0100, Bastien Nocera wrote: > > I suspect GNOME might be interested in having a "backup story" so I'm > > offering this one. And I'd be happy to have increased design advice > > and developer eyeballs. > > I'd really like Deja Dup to be even more integrated into the system, > meaning that we should make it possible to backup the whole system, > using fanotify(), and possibly integrating with btrfs snapshots. > I don't think we should aim for whole system backup really, but just user's data backup should be enough. Administrators know perfectly how to backup their systems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First release of geocode-glib available
On Mon, 2011-05-09 at 16:52 +0100, Bastien Nocera wrote: > This library should be used in place of Geoclue's D-Bus API for > geocoding and reverse geocoding. Is this now deprecated in the Geoclue API? It seems like there's an advantage to using an API that can have multiple providers. --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
dropping generation of old devhelp format in gtk-doc
Hi, In 2005 we created a new format for devhelp index files that contains more details. It is supported since devhelp-0.11 (18.Dec.2005). The next release of gtk-doc will not generate the old devhelp files anymore. This speeds up the builds a bit and saves some bytes on your hard-dives :) If I am overlooking something here, please let me know. Thanks, Stefan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: "Open containing folder" for all apps
Hi, Federico Mena Quintero wrote: > In summary, while one can go *down* in the file system hierarchy with > Nautilus to open a file, one cannot go *up* from the opened file back > into the file system (presumably to explore files that are "near" the > one you had open). Of course with symbolic/real links it can sometimes be hard to know what directory a file is in, but you can tell what pathname was sent to the application, and using the dirname from that should be enough. > Firefox has an "Open in file manager" command for its downloads, which > is pretty useful. I find Evince's "Open containing folder" command > invaluable when I'm organizing PDFs to drag them to a better place. I really miss this feature (and the related feature I'd like to see of storing recently used folders as well as recently used files). Some of the use-cases I've found are: * When you want to "Save as..." to save a modified copy of a document without crushing the original, I'd like the folder to be automatically set to the containing folder of the original. In general, I want to save related documents in proximity to each other. * I often want to get the path to original file in Rhythmbox or Shotwell, and there really is no easy way to do it. Reasons why I might want to get the path to the original? To move from the app to the file manager to copy (say) all the photos taken on a particular date, or to rename an "Untitled album" that I've ripped when I was offline to something more meaningful, or to simply get the original of a photo to send to someone (although Shotwell's "Send to" functionality has improved enormously over the last year). * For "Recent folders": Saving attachments to emails. I get attachments related to a project, and I want to save them in the same place. So I right click->"Save as" in one email, navigate to where it should be saved, save, and then move to a new email, right click->"Save as", and have to repeat navigation. A lot of this would be improved by simply improving the memory of applications re the last folder they used, but like Federico, I'd really be able to go from "file in application" to "file on filesystem", in the same way I can do the inverse. 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: dropping generation of old devhelp format in gtk-doc
Stefan Kost wrote: > In 2005 we created a new format for devhelp index files that contains more > details. It is supported since devhelp-0.11 (18.Dec.2005). The next release of > gtk-doc will not generate the old devhelp files anymore. This speeds up the > builds a bit and saves some bytes on your hard-dives :) > > If I am overlooking something here, please let me know. library-web (used to generate developer.gnome.org) was still parsing .devhelp files in some places, I just pushed a fix. Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Il giorno mar, 10/05/2011 alle 21.51 -0500, Jason D. Clinton ha scritto: > On Tue, May 10, 2011 at 19:15, Luca Ferretti wrote: > > #3 -- I feel this "no-API for gnome-cc" approach crashes with planned > > and upcoming changes in GNOME Desktop modules definition > > There is no GNOME Desktop module; we now have only core, platform and > bindings. What are you speaking of? In fact I wrote "GNOME Desktop modules", I suspect we still have a "GNOME Desktop" project and two or more modules :P However, as I said, I could missed something in latest weeks, but I'm sure the transition from external/platform/desktop/admin/development to core/other (where other mainly means applications) is still not complete. > >, as well as > > with the idea of "GNOME as platform for everyone" > > What is this and where was it proposed? If not, what is GNOME? A self-sustained, self-contained project? Of course it's a great desktop for end users, but IMHO it's also -- or it should be -- an opportunity for developers. External developers. I.e. people that create software outside git.gnome.org. People that create software for fun, for profit or for fun&profit. So I suspect there is no need to propose now "GNOME as platform for everyone", it should be for everyone from its own creation. > >. This proposal from > > Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a "core" > > module (as per current definition of core: only stuff needed to start > > user session), but it's perfect as "approved by GNOME" module. > > No, we do not have any such plans to approve or disapprove of modules. > If they are outside of core, platform or bindings, the only official > designation is that they might be featured in our marketing. That's > it. We do not bless modules any more. Oh, sorry, then I used the wrong word. Please consider approved==featured. > > Also, > > IMHO the UI proposed changes to Deja-dup preferences are well designed > > for GNOME 3 experience (backup as a service, not as user launchable > > app). So, this seems to be a contradiction: we can't place you in core, > > but we don't want to provide the ability for a proper integration. Also, > > what about third parts, vendors and distros? > > That's a technical problem, not political. I don't understand. What do you mean with "technical" and "political"? > > > For instance, Ubuntu > > provides a really useful Additional Drivers tool and I suppose the best > > place for it is System Settings > Hardware; same for Prey > > (http://preyproject.com/) and it's configuration panel. Are we going to > > make GNOME a closed desktop? > > Again, technical. Again, I don't understand. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi Michael, 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. It's great that you're reapplying for inclusion, and backup would be good to have. I'm really happy that you want your software to be a part of GNOME. > 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. That sounds like the right approach to me. > 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. 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!'). I do think this should be part of system settings, provided Deja Dup behaves like it is part of the system. 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? > I suspect GNOME might be interested in having a "backup story" so I'm > offering this one. And I'd be happy to have increased design advice > and developer eyeballs. As others have suggested, that story should roughly be 'backup that just works': you switch it on, do some very minimal configuration, and then it takes care of itself in the background. > I have a few related questions: > * What does being a GNOME Feature obligate me to? Basically the > normal module stuff? (Since no one else has answered this question...) In this case, yes (I think!) Best wishes, 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]
Il giorno mer, 11/05/2011 alle 01.27 +0100, Bastien Nocera ha scritto: > On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: > > #2 -- will gnome-c-c module englobe _all_ chosen panels? who will > > approve them? g-cc maintainers? release team? design team? a pool on > > doodle.com :P )? > > Maintainers and designers. Maintainers meaning that if it's not > designed, it won't go in. So really, designers. Will designers approve external dependencies too? It's just an example, but... Deja-dup needs duplicity. Deja-dup, converted to "Backup" panel inside gnome-control-center, will make gnome-control-center depends on duplicity (unless maintainer will make it optional, but I suspect designers can say "we want this feature by design" and promote it to mandatory). gnome-control-center is part of GNOME Desktop core. GNOME Desktop core depends on duplicity... I love Aristotelian syllogism :) > The "System Settings" isn't a random dumping ground for preferences. If > we (we being the designers, and then the maintainers, in that order) > don't think that the setting belongs in the System Settings, then it > won't go in there. IIRC, I never seen this statement during 3.0 development. Nobody said "you will not able to plug third part panel to System Settings". It was proposed as "we are going to move from menus and separate dialogs to single window". Empathy and krb5-auth-dialog developed their own panels and nobody stopped developers to waste their own time... > For backup, as I mentioned, we're not averse to having backup, but the > preferences will need to go through design before that happens. > > As for "preyproject" (their website not working seriously hampering what > I could find out about it), it seems that most of the functionality > would be in the privacy and sharing panel. Those 2 was just examples of external stuff that could be better suited as system settings panel :) There are much more stuff outside and inside git.gnome.org :) > We started moving things into gnome-control-center so we could stop the > various panels looking like they were a hodge-podge of thrown together > bits. Opening the door to 3rd-party panels would 1) get us the bug > reports 2) destroy the work we carefully crafted. And closing the doors IMHO means to follow, sorry to be impolite and a little offensive, a really stupid and dumb path. You are proving a resource, but you don't want other developers and vendors will be able to take advantage of it. It resembles to me a childish "this is MY toy, I choose who can play". A diktat: in or out. More, you are staring from a negative point of view. Maybe someone will be able to provide a beautiful and well integrated external panel for system setting, deja-dup proposal is a perfect example. A project taking care to be well integrated in chosen design. It could be a win-win game. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Hi, Allan. Thanks for your past and continuing help with design! :) Answers below. On 11 May 2011 11:33, Allan Day 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. > 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. -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:02 +1000, Danielle Madeley wrote: > On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: > > > > #1 -- was this announced/proposed to desktop-devel-list? > > > > No, because it was only made for one particular module > > (gnome-bluetooth), and by me. The reason we had an external API was so > > that gnome-bluetooth code happen in time for 3.0. And we've reverting it > > to 3.2. > > Empathy has some control-center shell integration as well for its > accounts configuration. Or perhaps it's an old version of the API. It > was primarily done for Meego Netbook. That will hopefully be superseded by the Web Accounts panel David is working on. > Although I endorse design of the core components, I don't think it has > to require the component to exist in gnome-cc. Furthermore, this seems > like a fairly arbitrary limitation. Both major non-free desktops permit > applications to install control-center. That's because Apple and Microsoft probably wouldn't be very receptive to adding functionality they don't have control over to the control-center. The control-center is still open source, and you can revert the patch that will make the library private, or, better, you can patch support for your functionality in the system settings and ask for integration upstream. Leaving the door open to the developer community to add new tabs gets us in the same tough spot as during the GNOME 2.x days. You end up with an unwieldy number of panels, and very little thought it what should go where. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 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. I'd be happy to see design work go into backup as a first class citizen in the GNOME desktop, and I hope this will nudge you in that direction. Drop by #gnome-design, and ask about examples of the previous design work we did. I'm sure we can get you going in the right direction for GNOME. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 10:14 +0200, Rodrigo Moya wrote: > On Wed, 2011-05-11 at 07:32 +0200, Michael Terry wrote: > > So as the Deja Dup maintainer, life will go on when you drop support. > > Worst case, I can just make the panel a dialog. > > > > But dropping the existing API feels like a frustrating bait and > > switch. It was not clear (at least to me) that this was your > > intentional all along, so myself and others made plans and put effort > > into making panels. > > > while I'm not sure making the API private is the best idea, I really > understand the reasons behind that decision, which is to not allow for a > control-center crowded with lots of crazy panels, specific to > applications. > > But backup is indeed something that makes a lot of sense as a System > Settings panel, so I think it could probably be integrated into > gnome-control-center itself. So, what are the dependencies the c-c panel > in Deja Dup has? > > So, getting some design for this would be a good thing, so that we can > start integrating it into the control center itself. > > Also, another solution might be to keep the g-c-c API public, but have a > whitelist, so that we just list there the panels that we bless and that > will be loaded in the g-c-c shell. Others would just be ignored, and so > distributions can choose to add the panels they want to the whitelist. If the whitelist is changeable (well, it always is, really), you lose. You're just shifting the responsibility from the upstream maintainers to the downstream maintainers. But it will still be upstream getting the blame for the bad design, eg. GNOME will be blamed for the system settings being a random collection of bits, when we're designing an OS. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On Wed, 2011-05-11 at 10:16 +0200, Rodrigo Moya wrote: > On Tue, 2011-05-10 at 20:51 +0100, Bastien Nocera wrote: > > > I suspect GNOME might be interested in having a "backup story" so I'm > > > offering this one. And I'd be happy to have increased design advice > > > and developer eyeballs. > > > > I'd really like Deja Dup to be even more integrated into the system, > > meaning that we should make it possible to backup the whole system, > > using fanotify(), and possibly integrating with btrfs snapshots. > > > I don't think we should aim for whole system backup really, but just > user's data backup should be enough. Administrators know perfectly how > to backup their systems Administrators aren't a magic people. When you have a personal machine, you're the administrator. Time Machine has shown how to do backups in a sane way. I'd hope that we can achieve the same level of integration, and ease of setup. Right now, making backups requires too much work, and people don't do it. I'd really like it to be much simpler and straight-forward. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : > On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: > > On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: > > > > > > #1 -- was this announced/proposed to desktop-devel-list? > > > > > > No, because it was only made for one particular module > > > (gnome-bluetooth), and by me. The reason we had an external API was so > > > that gnome-bluetooth code happen in time for 3.0. And we've reverting it > > > to 3.2. > > > > Empathy has some control-center shell integration as well for its > > accounts configuration. Or perhaps it's an old version of the API. It > > was primarily done for Meego Netbook. > > That will hopefully be superseded by the Web Accounts panel David is > working on. But shouldn't we wait that the Web accounts panel is actually a full super-set of Empathy's panel (and not just some mockups) before removing the lib? G. -- Guillaume Desmottes Jabber GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 12:03, Bastien Nocera wrote: > Administrators aren't a magic people. When you have a personal machine, > you're the administrator. > > Time Machine has shown how to do backups in a sane way. I'd hope that we > can achieve the same level of integration, and ease of setup. > > Right now, making backups requires too much work, and people don't do > it. I'd really like it to be much simpler and straight-forward. As someone who has several Macs at home, I endorse the message that Time Machine is serious magic and should be cloned as soon as possible. :) 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 Wed, 2011-05-11 at 10:03 +0200, Dave Neary wrote: > Hi, > > Michael Terry wrote: > > My plans have always been aimed at personal data only, with any > > support for whole-system backup as a nice bonus. There are technical > > issues there like "if you hit a file the user doesn't have read > > support for, are you going to prompt for the root password every > > time?" > > FWIW, this is exactly the use-case I'm missing. I would like to copy my > personal data to an external hard drive, remote server or cloud storage > service, so that if my hard drive goes boom, I can get my settings, > documents, photos, etc back after installing a new distribution on a new > system. I'm not that bothered about a full system recovery for a GNOME > back-up tool. > > So I applaud your focus :) That's because you're lead to believe that it's enough :) We have the concept of user roles in PolicyKit. If the person is marked as the "administrator", they can change the backup settings, and they're the ones whose credentials should be used during backup. Say my hard drive died. How do I get back to a working desktop with my documents from my distribution's live CD? If the process is tedious, or complicated, then it's no use. FWIW, Time Machine uses a disk image on a remote AFP share. The machine which you'll be backing up is the one with rights to update that image (so the backup system works as a privileged user). Access to the files is restricted through Unix permissions on the disk image which match one-to-one the permissions on the local disk. Thus, you can have multi-user systems where the whole system is backed up even if it's not the person who set up the backup that's logged in. I'd like to note one particular tidbit about backups. Backing up is easy, it's the restore that's hard. And I'm sure I'm not the only person that's worked in tech support that ended up shaking their heads when the person on the other end of the line was doing backups but never tested restoring (or didn't know how to). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 13:05 +0200, Guillaume Desmottes wrote: > Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : > > On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: > > > On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: > > > > > > > > #1 -- was this announced/proposed to desktop-devel-list? > > > > > > > > No, because it was only made for one particular module > > > > (gnome-bluetooth), and by me. The reason we had an external API was so > > > > that gnome-bluetooth code happen in time for 3.0. And we've reverting it > > > > to 3.2. > > > > > > Empathy has some control-center shell integration as well for its > > > accounts configuration. Or perhaps it's an old version of the API. It > > > was primarily done for Meego Netbook. > > > > That will hopefully be superseded by the Web Accounts panel David is > > working on. > > But shouldn't we wait that the Web accounts panel is actually a full > super-set of Empathy's panel (and not just some mockups) before removing > the lib? Of course, yes. And I didn't have time to work on moving gnome-bluetooth into the control-center either. I guess this'll serve as a warning to people who wanted to install their own panels. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: "Open containing folder" for all apps
On Tue, 2011-05-10 at 22:58 +0200, Milan Bouchet-Valat wrote: > Le mardi 10 mai 2011 à 19:13 +0100, Bastien Nocera a écrit : > > > So, what do you think? The patches for apps should be pretty small, and > > > they really provide much better circulation within your files. > > > > And applications that can "send out" files, could also add a little menu > > item to send it out using nautilus-sendto (the API there being > > "nautilus-sendto filename"). Evolution, Totem, Rhythmbox and a number of > > others allow you to do that. > Couldn't there be a common menu in the Shell that would work like the > application menu, but for documents? I think it would be a real benefit > to know that in every app you use, you're able to perform common actions > on the opened file, without thinking "where's that button/menu again? > what app am I using?". > > As a rough sketch, we have three items, the two latter being menus: > [Activities][Application name:] [Document name] > > The Document menu would only be shown when the current window exports > some hint about the document it's currently editing, e.g. by a X > property on the window, which would be made easy via a simple GTK+ > function. (AFAIK Zeitgeit wouldn't work because it doesn't know about > the window, only about the application, which is needed for > multi-instance apps.) > > Does that sound completely mad? ;-) The shell menu is per-application. And that's not where the document lives. I think that such functionality should live next to the "Save" menu items because that's where you'd look. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: "Open containing folder" for all apps
On Tue, 2011-05-10 at 17:16 -0500, Federico Mena Quintero wrote: > On Tue, 2011-05-10 at 19:13 +0100, Bastien Nocera wrote: > > > And applications that can "send out" files, could also add a little menu > > item to send it out using nautilus-sendto (the API there being > > "nautilus-sendto filename"). Evolution, Totem, Rhythmbox and a number of > > others allow you to do that. > > Hey, nice idea. Dave Richards of the City of Largo found out that > people couldn't figure out how to send their documents to another > person, unless the app explicitly provides a "send to" command. > > Do we have a stock action/icon for this? We don't, but if nautilus-sendto is installed, the code is quite trivial: http://git.gnome.org/browse/rhythmbox/tree/plugins/sendto/sendto.py The biggest part of it is the code to insert the menu dynamically. Evolution doesn't have this sort of code, and just checks for "nautilus-sendto" in the path before showing the menu item. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
ons 2011-05-11 klockan 12:03 +0200 skrev Michael Terry: > 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. Encryption toggle: Since encryption requires a passphrase it is hard to get rid of, and for cloud storage it is very nice to have. Include/exclude: I think Exclude is still relevant (include should default to all personal data), since I (and probably a lot of other users) download stuff from the Internet that are very temporary, it can be movies, software installers aso... on my Mac I have added and exclude rule for the download folder since that would just waste space on my backup-unit. How long to keep backups: Forever or as long as there are storage left. I like the TimeCapsule version with a nice default algorithm that tries to keep as much as possible as long as possible. How often to back up: Always by monitoring the files. just my view... //Snaggen ___ 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 13:42, Mattias Eriksson wrote: > Include/exclude: I think Exclude is still relevant (include should default > to all personal data), since I (and probably a lot of other users) download > stuff from the Internet that are very temporary, it can be movies, software > installers aso... on my Mac I have added and exclude rule for the download > folder since that would just waste space on my backup-unit. Just a note: Default include is $HOME, default excludes are Trash and Downloads. There are secret excludes for common cache directories too. > How long to keep backups: Forever or as long as there are storage left. I > like the TimeCapsule version with a nice default algorithm that tries to > keep as much as possible as long as possible. The collapsing of older backups is tough with this backup format. Duplicity does not assume it can run code on the backend, so it can't really do a logarithmic collapsing of backups as they get older (unless it downloaded, collapsed, uploaded). I agree it would be a nice feature though. -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
Le mercredi 11 mai 2011 à 13:47 +0200, Michael Terry a écrit : > > How long to keep backups: Forever or as long as there are storage left. I > > like the TimeCapsule version with a nice default algorithm that tries to > > keep as much as possible as long as possible. > > The collapsing of older backups is tough with this backup format. > Duplicity does not assume it can run code on the backend, so it can't > really do a logarithmic collapsing of backups as they get older > (unless it downloaded, collapsed, uploaded). I agree it would be a > nice feature though. Why not just ask the user when performing a new backup in case there's not enough space left? Since DéjàDup already does full backups from time to time, it could notice the user that in order to backup new data, s/he needs to get rid of older versions until the date of a full backup (chosen so that just enough data can be freed to make the new one). That way, we can get rid of the somewhat scary setting "How long too keep backups". Cheers ___ 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 1:57 PM, Milan Bouchet-Valat wrote: > Why not just ask the user when performing a new backup in case there's > not enough space left? Since DéjàDup already does full backups from time > to time, it could notice the user that in order to backup new data, s/he > needs to get rid of older versions until the date of a full backup > (chosen so that just enough data can be freed to make the new one). > > That way, we can get rid of the somewhat scary setting "How long too > keep backups". And if you're not there it will passively let you lose data :) "How long to keep backups" should really be named something like "how many copies to keep" with possible options such as "just the last one", "entire last month" or "eleven most recent ones". -- Patryk Zawadzki I solve problems. ___ 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 13:57, Milan Bouchet-Valat wrote: > Why not just ask the user when performing a new backup in case there's > not enough space left? Since DéjàDup already does full backups from time > to time, it could notice the user that in order to backup new data, s/he > needs to get rid of older versions until the date of a full backup > (chosen so that just enough data can be freed to make the new one). When disk space is low, the oldest backup is already deleted to make room. I just meant it is hard to implement 'telescoping' backups where we only keep monthly backups from 1 year ago, weekly backups from a month ago, etc. -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, May 11, 2011 at 7:05 AM, Guillaume Desmottes wrote: > Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : >> >> That will hopefully be superseded by the Web Accounts panel David is >> working on. > > But shouldn't we wait that the Web accounts panel is actually a full > super-set of Empathy's panel (and not just some mockups) before removing > the lib? No. We don't want the crazy (sorry...) list of chat protocols in there, I think. The way I envision this to work for both empathy and for evolution is that the apps will pick up configuration for the major web accounts (google, facebook,...) from the web accounts panel, but still offer their own configuration for things like bare imap (in evo) or irc (in empathy). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: > > > Although I endorse design of the core components, I don't think it > has > > to require the component to exist in gnome-cc. Furthermore, this > seems > > like a fairly arbitrary limitation. Both major non-free desktops > permit > > applications to install control-center. > > That's because Apple and Microsoft probably wouldn't be very receptive > to adding functionality they don't have control over to the > control-center. I cannot say for Apple but I've seen drivers and applications that modify Windows Control Panel (i.e. add components). Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 14:03 +0100, Maciej Piechotka wrote: > On Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: > > > > > Although I endorse design of the core components, I don't think it > > has > > > to require the component to exist in gnome-cc. Furthermore, this > > seems > > > like a fairly arbitrary limitation. Both major non-free desktops > > permit > > > applications to install control-center. > > > > That's because Apple and Microsoft probably wouldn't be very receptive > > to adding functionality they don't have control over to the > > control-center. > > I cannot say for Apple but I've seen drivers and applications that > modify Windows Control Panel (i.e. add components). > > Regards Sorry if I'm reposting this - Evolution failed with unknown error during sending due to network failure. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
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. > > I suspect GNOME might be interested in having a "backup story" so I'm > offering this one. And I'd be happy to have increased design advice > and developer eyeballs. +1 for extra applications. I think there are many valid use-cases when backup is not needed (kiosk, /home on NFS with internal backup). Currently I'm missing: - The off-line storing to external hardware. I.e. I have relatively small disk in laptop so I cannot store too much on it. The same goes for network. Preferable I'd like: - Make backup daily to disk. Preferably with vary low priority - When I connect disk to computer I'd like to have copy all backups automatically - The snapshot feature. Many FS (say ZFS) or block devices (LVM) allows to create a snapshot of disk. The deja-dup possibly could policykit to allow snapshot of volume: DD: I'd like to snapshot $HOME Daemon (I assume after auth): (a) Here it is /mnt/snapshot/XYZABC DD: Uses /mnt/snapshot/XYZABC to backup DD: Ok. I don't use it anymore (b) I cannot make it DD: ok (do backup directly) For large $HOME it may be preferable Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:58 +0100, Bastien Nocera wrote: > On Wed, 2011-05-11 at 10:14 +0200, Rodrigo Moya wrote: > > Also, another solution might be to keep the g-c-c API public, but have a > > whitelist, so that we just list there the panels that we bless and that > > will be loaded in the g-c-c shell. Others would just be ignored, and so > > distributions can choose to add the panels they want to the whitelist. > > If the whitelist is changeable (well, it always is, really), you lose. > You're just shifting the responsibility from the upstream maintainers to > the downstream maintainers. But it will still be upstream getting the > blame for the bad design, eg. GNOME will be blamed for the system > settings being a random collection of bits, when we're designing an OS. Downstream has emacs and gcc too. It's changeable anyway. If we're designing an OS, we need better control of our supply chain. -- 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 Re: GNOME Feature Proposal: Backup]
Em Qua, 2011-05-11 às 11:37 +0200, Luca Ferretti escreveu: > Il giorno mer, 11/05/2011 alle 01.27 +0100, Bastien Nocera ha scritto: > > On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: > > > > #2 -- will gnome-c-c module englobe _all_ chosen panels? who will > > > approve them? g-cc maintainers? release team? design team? a pool on > > > doodle.com :P )? > > > > Maintainers and designers. Maintainers meaning that if it's not > > designed, it won't go in. So really, designers. > > Will designers approve external dependencies too? > > It's just an example, but... Deja-dup needs duplicity. Deja-dup, > converted to "Backup" panel inside gnome-control-center, will make > gnome-control-center depends on duplicity (unless maintainer will make > it optional, but I suspect designers can say "we want this feature by > design" and promote it to mandatory). gnome-control-center is part of > GNOME Desktop core. GNOME Desktop core depends on duplicity... I love > Aristotelian syllogism :) > > Just because deja-dup depends on duplicity doesn't mean the control center panel needs to as well. It doesn't even have to depend on deja-dup, instead proposing its installation like Totem and file-roller handle non-installed formats. > > More, you are staring from a negative point of view. Maybe someone will > be able to provide a beautiful and well integrated external panel for > system setting, deja-dup proposal is a perfect example. A project taking > care to be well integrated in chosen design. It could be a win-win game. > I think the starting point here is not a negative point of view, it's how GNOME evolved from 2.0 to 2.32 as shipped in most GNOME distributions. Inviting application developers that want proper integration with GNOME to work with GNOME designers is a perfectly valid way to handle this situation. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Le mercredi 11 mai 2011 à 08:44 -0400, Matthias Clasen a écrit : > On Wed, May 11, 2011 at 7:05 AM, Guillaume Desmottes > wrote: > > Le mercredi 11 mai 2011 à 11:47 +0100, Bastien Nocera a écrit : > > >> > >> That will hopefully be superseded by the Web Accounts panel David is > >> working on. > > > > But shouldn't we wait that the Web accounts panel is actually a full > > super-set of Empathy's panel (and not just some mockups) before removing > > the lib? > > No. We don't want the crazy (sorry...) list of chat protocols in > there, I think. The way I envision this to work for both empathy and > for evolution is that the apps will pick up configuration for the > major web accounts (google, facebook,...) from the web accounts panel, > but still offer their own configuration for things like bare imap (in > evo) or irc (in empathy). And what happen if Empathy fades away, if Gnome Shell becomes the Telepathy Handler ? Does it mean Gnome will no longer support less known protocols ? Nicolas signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 13:24, Michael Terry wrote: > When disk space is low, the oldest backup is already deleted to make > room. I just meant it is hard to implement 'telescoping' backups > where we only keep monthly backups from 1 year ago, weekly backups > from a month ago, etc. FWIW, that's what Time Machine does. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On May 11, 2011 3:46 AM, "Luca Ferretti" wrote: > > >, as well as > > > with the idea of "GNOME as platform for everyone" > > > > What is this and where was it proposed? > > If not, what is GNOME? A self-sustained, self-contained project? Of > course it's a great desktop for end users, but IMHO it's also -- or it > should be -- an opportunity for developers. External developers. I.e. > people that create software outside git.gnome.org. People that create > software for fun, for profit or for fun&profit. > > So I suspect there is no need to propose now "GNOME as platform for > everyone", it should be for everyone from its own creation. I like it but we do have a entire marketing team which would need to think about it and its impact on messaging. Please propose it there. ___ 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 mercredi 11 mai 2011 à 12:16 +0100, Bastien Nocera a écrit : > > FWIW, this is exactly the use-case I'm missing. I would like to copy > my > > personal data to an external hard drive, remote server or cloud > storage > > service, so that if my hard drive goes boom, I can get my settings, > > documents, photos, etc back after installing a new distribution on a > new > > system. I'm not that bothered about a full system recovery for a > GNOME > > back-up tool. > > > > So I applaud your focus :) > > That's because you're lead to believe that it's enough :) From desktop point of view, we usually do no modification of any kind except for /home. It takes 20-30 minutes to install a distro these days, and same to install a system backup. Base on that, doing a full system backup seems a waste to me. As long as I can recover my home into some newly created user account, I think it's enough. Also, when a hard disk breaks, I tend to buy a bigger one. Using distribution installer let me reconfigure the partitioning (or let the distro do it) from an user interface I already learned before. For sure, if your looking for server backup it's a different story. But in reality, servers these days are not backup using integrated UI. Most of the time, server are virtual, which makes backups something really different. Also, my previous experience trying to help someone using Time Machine and Time Capsule on OS X was not so great. It ended up using the capsule as a hard-drive and simply copying manually stuff over, as it was much simpler to get stuff back. The tech support argument is interesting, but my corporate experience tells me that we never endup having full system backup for user Desktop). The reason is that it's time and disk consuming. What I've seen the most, is user profile being store on central server, and tools to track software and licenses on each desktop. I'm guessing on this one, but also tools to reinstall from the ground those machine with the same softwares and licenses. At last, I don't think the futuristic system wide backup should delay having per-user backup. When this advance system wide backup support exist, we could simply improve the UI and give more options to administrators, and if an admin has setup system wide backup, cleanly inform the non-privileged user that backup is already configured by the system administrator. I would be really surprised such a complex system wide tool gets written and reach a solid state soon, and even there, I would be really surprise if sys-admin would start using such a young implementation right away. Also, restoring user home from a user setting is quite simple, but restoring a full system requires alternative OS, which is usually distro expertise, not a UX expertise (I don't agree Gnome 3 is an OS, but its clearly a UX). cheers, Nicolas signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Le mardi 10 mai 2011 à 15:49 +0200, Michael Terry a écrit : > 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. To be a part of the OS, I think Déjà Dup should also allow to save system settings. Exemple, based on your mockups: Have a "System"[1] section, under the "Files" section, with a simply list of items to save. Items could be "Printers settings", "Network settings", "Users XXX settings", "Users YYY settings", "List of softwares and sources installed", etc... But it's only my thinkk. ;) -- Gendre Sebastien 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
BTW, it seems like there's a bit of feeling-as-we-go about the optimal design and feature set here. Maybe I could sit down with some GNOME designers like Allan and talk about what their ideal backup experience is and they can talk to me about current Deja Dup behavior and features? It could be over IRC or something. I just feel like a real-time discussion with designers would clarify to them what the shape of the Deja Dup experience is, its limitations, and where it can be changed. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping generation of old devhelp format in gtk-doc
On 11.05.2011 11:37, Frederic Peters wrote: > Stefan Kost wrote: > >> In 2005 we created a new format for devhelp index files that contains more >> details. It is supported since devhelp-0.11 (18.Dec.2005). The next release >> of >> gtk-doc will not generate the old devhelp files anymore. This speeds up the >> builds a bit and saves some bytes on your hard-dives :) >> >> If I am overlooking something here, please let me know. > library-web (used to generate developer.gnome.org) was still parsing > .devhelp files in some places, I just pushed a fix. > thanks for the quick fix. I just pushed the patch - still some time before next release. commit 0e91e9874859a4c5e92f9442e069dd9bdd9dbc3f Author: Stefan Kost Date: Wed May 11 11:13:09 2011 +0300 devhelp: remove generation of old devhelp files We're supporting devhelp2 files since 2005. Those are supported since devhelp-0.11 (18.Dec.2005). Dropping them speeds up the builds a bit and saves some bytes peoples hard-drives. ___ 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-11 at 10:18 -0400, Nicolas Dufresne wrote: > Le mercredi 11 mai 2011 à 12:16 +0100, Bastien Nocera a écrit : > > > FWIW, this is exactly the use-case I'm missing. I would like to copy > > my > > > personal data to an external hard drive, remote server or cloud > > storage > > > service, so that if my hard drive goes boom, I can get my settings, > > > documents, photos, etc back after installing a new distribution on a > > new > > > system. I'm not that bothered about a full system recovery for a > > GNOME > > > back-up tool. > > > > > > So I applaud your focus :) > > > > That's because you're lead to believe that it's enough :) > > From desktop point of view, we usually do no modification of any kind > except for /home. It takes 20-30 minutes to install a distro these days, > and same to install a system backup. Base on that, doing a full system > backup seems a waste to me. You just lost what applications were installed, and all your Bluetooth setup. If you were a web developer, you also lost your Apache, MySQL, whatever config files, and possibly your root web directory. Oh, and you also lost the home directories for whoever share your machine and didn't do a complete backup beforehand. > As long as I can recover my home into some > newly created user account, I think it's enough. Also, when a hard disk > breaks, I tend to buy a bigger one. Using distribution installer let me > reconfigure the partitioning (or let the distro do it) from an user > interface I already learned before. > > For sure, if your looking for server backup it's a different story. But > in reality, servers these days are not backup using integrated UI. Most > of the time, server are virtual, which makes backups something really > different. > > Also, my previous experience trying to help someone using Time Machine > and Time Capsule on OS X was not so great. It ended up using the capsule > as a hard-drive and simply copying manually stuff over, as it was much > simpler to get stuff back. You found a bug in software. But we would have the source code for our backup solution, and we could fix it. > The tech support argument is interesting, but my corporate experience > tells me that we never endup having full system backup for user > Desktop). The reason is that it's time and disk consuming. What I've > seen the most, is user profile being store on central server, and tools > to track software and licenses on each desktop. I'm guessing on this > one, but also tools to reinstall from the ground those machine with the > same softwares and licenses. You don't have to copy "everything" on the disk. You can very well see what files have been changed compared to the "package" installation and only backup the changed files. You can also whitelist particular directories. The point being that you should be able to restore something that contains all the documents of the local users, and a system installation that resembles what you had. The package versioning probably doesn't need to be the same, but being able to do backup/restore for upgrades, or hardware failure seems like the right thing to do. Backup should be system-wide, otherwise it might as well be a script in my home directory. > At last, I don't think the futuristic system wide backup should delay > having per-user backup. When this advance system wide backup support > exist, we could simply improve the UI and give more options to > administrators, and if an admin has setup system wide backup, cleanly > inform the non-privileged user that backup is already configured by the > system administrator. I would be really surprised such a complex system > wide tool gets written and reach a solid state soon, and even there, I > would be really surprise if sys-admin would start using such a young > implementation right away. Also, restoring user home from a user setting > is quite simple, but restoring a full system requires alternative OS, > which is usually distro expertise, not a UX expertise (I don't agree > Gnome 3 is an OS, but its clearly a UX). If we didn't talk to OS components, or implement them, we wouldn't have PulseAudio, NetworkManager, bluez, systemd, etc. Thinking that we live in the bubble of "user interface" just isn't true. ___ 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-11 at 10:18 -0400, Nicolas Dufresne wrote: > Le mercredi 11 mai 2011 à 12:16 +0100, Bastien Nocera a écrit : > > > FWIW, this is exactly the use-case I'm missing. I would like to copy > > my > > > personal data to an external hard drive, remote server or cloud > > storage > > > service, so that if my hard drive goes boom, I can get my settings, > > > documents, photos, etc back after installing a new distribution on a > > new > > > system. I'm not that bothered about a full system recovery for a > > GNOME > > > back-up tool. > > > > > > So I applaud your focus :) > > > > That's because you're lead to believe that it's enough :) > > From desktop point of view, we usually do no modification of any kind > except for /home. It takes 20-30 minutes to install a distro these days, > and same to install a system backup. Base on that, doing a full system > backup seems a waste to me. As long as I can recover my home into some > newly created user account, I think it's enough. Also, when a hard disk > breaks, I tend to buy a bigger one. Using distribution installer let me > reconfigure the partitioning (or let the distro do it) from an user > interface I already learned before. Perhaps it's not time-consuming to install a distro, but it is time-consuming to work out what extra packages/software one had installed and then find and reinstall them. If a GNOME backup program is not going to back up anything outside the home directory, I'd at least hope that it would store a list with each backup of the packages the user has installed. I believe PackageKit offers such functionality[1] (though I've never actually seen it). Philip [1]: http://blogs.gnome.org/hughsie/2008/11/15/pkcon-list-install-foopackage-list/ > For sure, if your looking for server backup it's a different story. But > in reality, servers these days are not backup using integrated UI. Most > of the time, server are virtual, which makes backups something really > different. > > Also, my previous experience trying to help someone using Time Machine > and Time Capsule on OS X was not so great. It ended up using the capsule > as a hard-drive and simply copying manually stuff over, as it was much > simpler to get stuff back. > > The tech support argument is interesting, but my corporate experience > tells me that we never endup having full system backup for user > Desktop). The reason is that it's time and disk consuming. What I've > seen the most, is user profile being store on central server, and tools > to track software and licenses on each desktop. I'm guessing on this > one, but also tools to reinstall from the ground those machine with the > same softwares and licenses. > > At last, I don't think the futuristic system wide backup should delay > having per-user backup. When this advance system wide backup support > exist, we could simply improve the UI and give more options to > administrators, and if an admin has setup system wide backup, cleanly > inform the non-privileged user that backup is already configured by the > system administrator. I would be really surprised such a complex system > wide tool gets written and reach a solid state soon, and even there, I > would be really surprise if sys-admin would start using such a young > implementation right away. Also, restoring user home from a user setting > is quite simple, but restoring a full system requires alternative OS, > which is usually distro expertise, not a UX expertise (I don't agree > Gnome 3 is an OS, but its clearly a UX). > > cheers, > Nicolas > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list 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: "Open containing folder" for all apps
On Wed, 2011-05-11 at 10:36 +0200, Dave Neary wrote: > I really miss this feature (and the related feature I'd like to see of > storing recently used folders as well as recently used files). Excellent use cases, Dave. I've just updated http://live.gnome.org/DocumentCentricGnome with details on all of what we discussed. There are two particularly important things, I think: - Show recent-folders explicitly in the collapsed "Save" dialog, instead of the meaningless drop-down of bookmarks. - Audit apps, based on the guidelines I posted in that page, to see whether they set the default filename/folder correctly depending on the situation. One detail of "Open if file manager" is that it is trivial to make apps call "nautilus --blahblah", but ideally this should be cross-desktop (and I imagine that Firefox and LibreOffice won't like to have Gnome-specific stuff like that). Maybe we need to add an option to xdg-open(1)? (Similar thing for "Send to..." and nautilus-sendto.) Federico ___ 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: > Hi, Allan. Thanks for your past and continuing help with design! :) > Answers below. > > On 11 May 2011 11:33, Allan Day 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: * 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. Sorry for the potentially difficult questions! Allan -- Blog: https://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
Hi Bastien! > You just lost what applications were installed, and all your Bluetooth > setup. If you were a web developer, you also lost your Apache, MySQL, > whatever config files, and possibly your root web directory. As has been mentioned before it would be enough to list the software packages installed and repos activated which is trivial with about every package manager I know of (and might be handled by PackageKit). For the web designer, I guess he would be inside when not using version control at some point but even if not he can easily add the files/directories he wants to backup manually. I guess we can find lots of special use cases where $HOME is not enough to backup but really those people needing it can configure it manually (with a nice UI). > Oh, and you also lost the home directories for whoever share your > machine and didn't do a complete backup beforehand. But what if Dave wants to backup to his external disk while Julia wants to update to her amazon cloud disk? It would of course be nice to have the option to backup /home/* but I am not sure if it is a good default option. > The point being that you should be able to restore something that > contains all the documents of the local users, and a system installation > that resembles what you had. The package versioning probably doesn't > need to be the same, but being able to do backup/restore for upgrades, > or hardware failure seems like the right thing to do. Storing only the changed files from the package installation has a point, but these seem to be very few on a normal desktop system. Ideally the number should be zero as most things are automatically configured on modern distros anyway. > > At last, I don't think the futuristic system wide backup should delay > > having per-user backup. When this advance system wide backup support > > exist, we could simply improve the UI and give more options to > > administrators, and if an admin has setup system wide backup, cleanly > > inform the non-privileged user that backup is already configured by the > > system administrator. I would be really surprised such a complex system > > wide tool gets written and reach a solid state soon, and even there, I > > would be really surprise if sys-admin would start using such a young > > implementation right away. Also, restoring user home from a user setting > > is quite simple, but restoring a full system requires alternative OS, > > which is usually distro expertise, not a UX expertise (I don't agree > > Gnome 3 is an OS, but its clearly a UX). > > If we didn't talk to OS components, or implement them, we wouldn't have > PulseAudio, NetworkManager, bluez, systemd, etc. Thinking that we live > in the bubble of "user interface" just isn't true. Still the point of starting with what we have now and improving it over time seems very valid to me compared to the "we will release is once we have really all the feature we want"-approach. 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 10 May 2011 20:10, Bastien Nocera wrote: > You'd need to ask Richard. I think the only reason it's not builtin to > the control-center is because it didn't go through design, but I might > be wrong. Well, I got shafted in GNOME 3, as I was told I shouldn't have installed a panel in the control panel without getting approval, and then the package got dropped by default in Fedora as it didn't fit in the design guidelines and we were already past the UI freeze. I guess I'm just a little bitter in retrospect. At the moment I've removed both the "Working spaces" and "Rendering intent" tabs as they didn't make much sense. I really want to better emphasize the need for a color managed workflow (where each input, display and output devices) have assigned profiles rather than split up the color profile assignment into the separate display, printer and unknown-type current panels and perhaps the current UI doesn't reflect that very well. 3.2 Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Hi Luca, On Wed, May 11, 2011 at 2:37 AM, Luca Ferretti wrote: > > > > We started moving things into gnome-control-center so we could stop the > > various panels looking like they were a hodge-podge of thrown together > > bits. Opening the door to 3rd-party panels would 1) get us the bug > > reports 2) destroy the work we carefully crafted. > > And closing the doors IMHO means to follow, sorry to be impolite and a > little offensive, a really stupid and dumb path. > > You are proving a resource, but you don't want other developers and > vendors will be able to take advantage of it. It resembles to me a > childish "this is MY toy, I choose who can play". A diktat: in or out. > > I think I understand the system settings.. it is in fact system settings, settings that change how your system behaves. It isn't exactly a place for apps to put themselves. That said, we don't really have a proper forum to educate developers on how to write applications the "GNOME 3" way. I realize we direct people to #gnome-design, but that's not really enough. To look at the big picture a bit, if we were to construct a life cycle of a GNOME application on how a developer goes about writing something in GNOME 3, we aren't going to get very far. For instance, developer.gnome.org is not anywhere on the gnome 3 site so an app developer at the moment really has to work at getting the information they need to get going. That's something some of us will need to work on... A simple construction of: in GNOME 3 - where do I store configurations? In GNOME 3, you must store configurations in gsettings and stored used in edit->preferences menu items. If you're app is a part of core GNOME 3, you may put your settings in system preferences Would help I think in giving application developers an idea where to do put their settings and avoid the abuse of system settings. You can illustrate using "good" applications that do it properly like say Rhythmbox and Totem. In the end, nobody can stop people from abusing the system settings if they wanted to. The source is out there and distros can just as easy revert whatever we do. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
jhbuild cairo checkout error
Hello,
I am beginning a build for gnome 3.0 on LFS 6.8 using jhbuild.
I am updating modules using:
http://ftp.gnome.org/pub/GNOME/teams/releng/3.0.0/gnome-suites-core-3.0.0.modules
http://ftp.gnome.org/pub/GNOME/teams/releng/3.0.0/gnome-suites-core-deps-3.0.0.modules
Relevant line from nobuild.jhbuildrc
use_local_modulesets = True
modulesets_dir = os.path.expanduser('~/modulesets')
moduleset = 'gnome-suites-core-3.0.0'
modules = [ 'meta-gnome-core' ]
nobuild = True
I get an error reported in logs:
error during stage checkout of cairo: Failed to find patch:
cairo-1.10.0-TrailingComma.patch
I can not locate this patch. I looked in 3.0.1 and they don't appear
different as far as this is concerned. I did not look at 3.1.
Am I using the wrong moduleset? Should I comment the line that
indicates the patch?
Any help is appreciated.
--
Thank you,
-Brian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 11:47 +0100, Bastien Nocera wrote: > On Wed, 2011-05-11 at 11:02 +1000, Danielle Madeley wrote: > > On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: > > > > > > #1 -- was this announced/proposed to desktop-devel-list? > > > > > > No, because it was only made for one particular module > > > (gnome-bluetooth), and by me. The reason we had an external API was so > > > that gnome-bluetooth code happen in time for 3.0. And we've reverting it > > > to 3.2. > > > > Empathy has some control-center shell integration as well for its > > accounts configuration. Or perhaps it's an old version of the API. It > > was primarily done for Meego Netbook. > > That will hopefully be superseded by the Web Accounts panel David is > working on. The last I heard, David's design was only for unifying, single-sign-on accounts such as Facebook and Google. Things that were pure IM accounts would still be in a separate capplet. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
