GNOME Feature Proposal: Backup
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. I have a few related questions: * What does being a GNOME Feature obligate me to? Basically the normal module stuff? * Déjà Dup lives in Launchpad. I'd love to explore ways of integrating the GNOME workflow and LP, but I would prefer that it remain in LP. I'm also happy to answer any questions about Déjà Dup, obviously. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Open containing folder for all apps
Hi, all, Per André's request to post features for Gnome 3.2 - here goes. A while ago I blogged about the problem of lack of circulation in our files, and posted a patch for Evince: http://people.gnome.org/~federico/news-2010-08.html#19 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). 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 think all apps that let you open documents or files should let you browse back to the file in the file manager. Akshay Gupta, in the CC for this mail, is my Summer of Code student who will be doing some things around file management, Finding and Reminding for gnome-shell, and such. One of his tasks is to produce patches for a few apps so that they have an Open in file manager command. Nautilus now lets us do this properly: https://bugzilla.gnome.org/show_bug.cgi?id=647204 So, what do you think? The patches for apps should be pretty small, and they really provide much better circulation within your files. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documentation build plans for 3.2
Shaun, What has happened to gnome-help package? I don't see it anymore in damned lies?! Regards. Sent from mobile device. Phone number: 00420 724 83 24 48 On May 8, 2011 7:47 PM, Shaun McCance sha...@gnome.org wrote: ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documentation build plans for 3.2
On Mon, May 9, 2011 at 18:01, Shaun McCance sha...@gnome.org wrote: On Mon, 2011-05-09 at 17:14 +0200, Jorge González wrote: Shaun, What has happened to gnome-help package? I don't see it anymore in damned lies?! This? Yeap, that. http://l10n.gnome.org/module/gnome-user-docs/ The POT file on DL is messed up, because DL doesn't know how to deal with all the new stuff I talked about. I'll get fixed. That's why we're doing this at the beginning of the cycle. Ok, thanks for the info, do you know how long will it take to DL to recognise the new formatting? Thanks in advance. -- Jorge González González alor...@gmail.com Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ 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 10/05/2011 00:29, Federico Mena Quintero wrote: Hi, all, Per André's request to post features for Gnome 3.2 - here goes. A while ago I blogged about the problem of lack of circulation in our files, and posted a patch for Evince: http://people.gnome.org/~federico/news-2010-08.html#19 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). 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 think all apps that let you open documents or files should let you browse back to the file in the file manager. Akshay Gupta, in the CC for this mail, is my Summer of Code student who will be doing some things around file management, Finding and Reminding for gnome-shell, and such. One of his tasks is to produce patches for a few apps so that they have an Open in file manager command. Nautilus now lets us do this properly: https://bugzilla.gnome.org/show_bug.cgi?id=647204 So, what do you think? The patches for apps should be pretty small, and they really provide much better circulation within your files. Federico Hmm. Maybe a better solution would be to somehow drag'n'drop? Say: - Attach xyz.pdf to e-mail: open xyz.pdf drag the window/contents of window to new mail window - Copy abc.gnumeric to CD - open file in gnumeric, drag'n'drop/contents of window to CD. From what I observed as 'family tech help' is that the users are at least sometimes confused by concept of 'file manager', 'file' or 'folder' (not that I'm using in description any of the word) and their first intuition to do something with file is to open it. I am not UI designer however. Regards PS. I know that DND of window will clash with moving it but maybe there is some smart way of doing it. ___ 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 Mon, 2011-05-09 at 18:29 -0500, Federico Mena Quintero wrote: Hi, all, Per André's request to post features for Gnome 3.2 - here goes. A while ago I blogged about the problem of lack of circulation in our files, and posted a patch for Evince: http://people.gnome.org/~federico/news-2010-08.html#19 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). 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 think all apps that let you open documents or files should let you browse back to the file in the file manager. Agreed there. Akshay Gupta, in the CC for this mail, is my Summer of Code student who will be doing some things around file management, Finding and Reminding for gnome-shell, and such. One of his tasks is to produce patches for a few apps so that they have an Open in file manager command. Nautilus now lets us do this properly: https://bugzilla.gnome.org/show_bug.cgi?id=647204 You might as well point to the canonical bug for it, or the commit. 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. Cheers ___ 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 18:10 +0100, Maciej Piechotka wrote: Hmm. Maybe a better solution would be to somehow drag'n'drop? Say: - Attach xyz.pdf to e-mail: open xyz.pdf drag the window/contents of window to new mail window - Copy abc.gnumeric to CD - open file in gnumeric, drag'n'drop/contents of window to CD. You are thinking of a different problem, specifically let me take the document I have open in front of me and pass it on to another tool. The problem I'm thinking of is, let me see things that I placed in the file system, close to the document I have open in front of me. (If your document were a book, my solution would be to have a sticker in the book's spine that tells you which bookcase and shelf to put it in when you are done with the book.) I am not UI designer however. This is OK. We all have intuitions as to how our tools should operate. Frequently those intuitions are correct; other times we need a larger vision - but you can learn that, as anything else. PS. I know that DND of window will clash with moving it but maybe there is some smart way of doing it. MacOS does this by showing an icon next to the filename in the window's titlebar: O O O [I] foobar.txt -- You can move the window by dragging the titlebar, but if you drag the [I], you instead drag the URL of the file (or something like that). *This* is a solution to your problem, but not to mine ;) 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
I think this is a great idea to have an well integrated backup program as part of the GNOME software suite. Looking at the screenshots and from testing some previous versions I have some thoughts. I think the schedule part of the settings is for advanced usage. By default I think a good backup program should monitor the file system for changes and do backup continuously, that way the user knows that everything is safe. Like if I connect my camera and import the pictures to my computer, I would like to just not have to care if the images are backed up or when they will be backed up I just want to delete the pictures on my camera knowing that a backup will exist as soon as possible. Also I think that a small status applet like on the mac would be great to have, since that will show the user that things are being backed up and provide a menu for the settings and forcing a backup. And a thought for future features... I saw that there were support for some cloud services for offsite backup, which is great! But is would be great for personal offsite backups (like http://www.crashplan.com/), where you install the software on multiple computers (your own or your friends) allowing them to store backup on each others disks. Anyway, these are just thoughts and suggestions... I really like deja-dup and hope it will be part of gnome and integrated in to the core. //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 10 May 2011 20:54, Mattias Eriksson snag...@acc.umu.se wrote: Looking at the screenshots and from testing some previous versions I have some thoughts. I think the schedule part of the settings is for advanced usage. By default I think a good backup program should monitor the file system for changes and do backup continuously, that way the user knows that everything is safe. Like if I connect my camera and import the pictures to my computer, I would like to just not have to care if the images are backed up or when they will be backed up I just want to delete the pictures on my camera knowing that a backup will exist as soon as possible. I would tend to agree that from the casual user's perspective, they just want a backup. I've so far resisted adding anything fancier than the ability to say every week or every month etc. But since I don't know how to do continuous detection well yet, I haven't done it. It would probably also want some design thinking for how to present feedback to the user in a more continuous context. Also I think that a small status applet like on the mac would be great to have, since that will show the user that things are being backed up and provide a menu for the settings and forcing a backup. There is a status icon used when backing up in classic GNOME. I was asked to remove it when the user is in the Shell. So I suspect GNOME designers would especially not like a status icon that is always there. And a thought for future features... I saw that there were support for some cloud services for offsite backup, which is great! But is would be great for personal offsite backups (like http://www.crashplan.com/), where you install the software on multiple computers (your own or your friends) allowing them to store backup on each others disks. Curious. Any GIO target is supported, so I suppose you could point at each other's machines if they are running SSH or some such, but that isn't quite as integrated as you mean. There is a long wishlist, but I've mostly been focusing on trying to tighten the experience rather than feature work. Thanks for your thoughts! -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 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. 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. 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 it's possible to have Deja Dup restore from bare metal right now, but I think this is what we should be aiming at, or at least allowing for re-install plus restore with minimal damage. I have a few related questions: * What does being a GNOME Feature obligate me to? Basically the normal module stuff? * Déjà Dup lives in Launchpad. I'd love to explore ways of integrating the GNOME workflow and LP, but I would prefer that it remain in LP. I'm also happy to answer any questions about Déjà Dup, obviously. Cheers ___ 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
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? ;-) Cheers ___ 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 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? Federico ___ 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: 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] That is interesting. I'm a bit dubious about making the app and document menus physically separate from the current window, but it's certainly a good idea to have standard actions for documents. 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. Thanks for resurrecting this idea - I blogged a little summary a while ago - http://people.gnome.org/~federico/news-2010-08.html#which-document Maybe it's time to discuss it again with the KDE people; Lubos raised some interesting points. 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
Bastien Nocera wrote: 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. It was also envisioned to have a colour management panel; what's the status on this? Is there some kind of guidance given for system settings that are not considered general enough for a settings panel? Straight to the tweak tool? Cheers, Frederic ___ 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 01:13 +0200, Frederic Peters wrote: Bastien Nocera wrote: 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. It was also envisioned to have a colour management panel; what's the status on this? 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. Is there some kind of guidance given for system settings that are not considered general enough for a settings panel? Straight to the tweak tool? That's really up to the designers. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Wait! Maybe I missed something (busy weeks, sorry), but... #1 -- was this announced/proposed to desktop-devel-list? #2 -- will gnome-c-c module englobe _all_ chosen panels? who will approve them? g-cc maintainers? release team? design team? a pool on doodle.com :P )? #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition, as well as with the idea of GNOME as platform for everyone. This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: Il giorno mar, 10/05/2011 alle 20.51 +0100, Bastien Nocera ha scritto: http://live.gnome.org/DejaDup/Screenshots/Future for screenshots. Déjà Dup 19.1, which includes those changes, is already in Fedora Rawhide and will be in Ubuntu Oneiric once we land the GNOME 3 control center. That won't work for long. Once we've move the Bluetooth panel directly in the control-center, we'll be removing the external API from the control-center. It was only added for gnome-bluetooth, and will be removed then as well. Wait! Maybe I missed something (busy weeks, sorry), but... #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. #2 -- will gnome-c-c module englobe _all_ chosen panels? who will approve them? g-cc maintainers? release team? design team? a pool on doodle.com :P )? Maintainers and designers. Maintainers meaning that if it's not designed, it won't go in. So really, designers. #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition, as well as with the idea of GNOME as platform for everyone. This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? The System Settings isn't a random dumping ground for preferences. If we (we being the designers, and then the maintainers, in that order) don't think that the setting belongs in the System Settings, then it won't go in there. For backup, as I mentioned, we're not averse to having backup, but the preferences will need to go through design before that happens. As for preyproject (their website not working seriously hampering what I could find out about it), it seems that most of the functionality would be in the privacy and sharing panel. Currently, there are 2 control-center modules that live outside System Settings, Bluetooth and the ibus configuration. The former should be merged in, and the latter should be merged with the layouts tab in region language, as designed. We started moving things into gnome-control-center so we could stop the various panels looking like they were a hodge-podge of thrown together bits. Opening the door to 3rd-party panels would 1) get us the bug reports 2) destroy the work we carefully crafted. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On Wed, 2011-05-11 at 01:27 +0100, Bastien Nocera wrote: #1 -- was this announced/proposed to desktop-devel-list? No, because it was only made for one particular module (gnome-bluetooth), and by me. The reason we had an external API was so that gnome-bluetooth code happen in time for 3.0. And we've reverting it to 3.2. Empathy has some control-center shell integration as well for its accounts configuration. Or perhaps it's an old version of the API. It was primarily done for Meego Netbook. ~ Although I endorse design of the core components, I don't think it has to require the component to exist in gnome-cc. Furthermore, this seems like a fairly arbitrary limitation. Both major non-free desktops permit applications to install control-center. -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On Tue, 2011-05-10 at 15:49 +0200, Michael Terry wrote: I'm also happy to answer any questions about Déjà Dup, obviously. I had a look at deja-dup, and was quite impressed at its simplicity. But I found it a bit difficult to recreate the kind of backup that I presently do with duplicity. I attached my current script for completeness, but here are the things that I found I couldn't figure out how to do with the existing UI: --encrypt-key 5CB48AEA \ --sign-key 5CB48AEA \ specify asymmetric encryption using my GPG key. --volsize 100 \ implementation detail, but it should be tweakable? --exclude '/home/andrew/**/*.o' \ I can tell it to ignore certain files or folders by name, but it doesn't seem I can exclude by pattern? As a developer there are an awful lot of intermediate files that I don't need to backup --exclude '/home/andrew/**/tmp/**/*.class' \ --exclude '/home/andrew/**/tmp/**/*.h' \ and so on. --exclude '/home/andrew/.gvfs' \ --exclude '/home/andrew/.local/share/gvfs-metadata' \ --exclude '/home/andrew/.cache' \ --exclude '**/*.cache' \ --exclude '**/Cache/**' \ If we're backing up a user's home directory, then ignoring all this stuff could just be automatic, right? --exclude '/home/andrew/.gnome2/epiphany/favicon_cache' \ --exclude '/home/andrew/.local/share/Trash' \ --exclude '/home/andrew/.Trash' \ --exclude '**/sessions' \ --exclude '/home/andrew/.nautilus/metafiles' \ --exclude '/home/andrew/.nautilus/saved*' \ --exclude '/home/andrew/.fontconfig' \ Ditto. And of course doing a system level backup, we don't need (and need to forceably skip): --exclude '/dev' \ --exclude '/proc' \ --exclude '/sys' \ --exclude '/tmp' \ --exclude '/var/lock' \ --exclude '/var/run' \ --exclude '/var/cache/apt' \ --exclude '/var/lib/apt/lists' \ --exclude '/var/log' \ --exclude '/media' \ --exclude '/mnt' \ And so on. Like I said, I like deja-dup, and its straight-forward UI. But given the sort of nuance above (and that everyone would want to tweak such things) could there be a default template of ignore, perhaps? Frankly, I'd prefer not to have to think about any of that - I just know that there are a ton of temporary or replaceable files that don't need to be backed up and when you're on a costly, time-limited, low-bandwidth link somewhere (ie travelling in the developing world) sending thumbnails and .o files isn't ideal. While this is clearly the sort of thing that could degenerate into a zillion configuration options and permutations, I'd like to hope GNOME's backup solution could help me out here and just Do The Right Thing™. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and effective procedures for change management: enabling successful deployment of mission critical information technology in enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London duplicate.sh Description: application/shellscript 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 Tue, May 10, 2011 at 19:15, Luca Ferretti lferr...@gnome.org wrote: #3 -- I feel this no-API for gnome-cc approach crashes with planned and upcoming changes in GNOME Desktop modules definition There is no GNOME Desktop module; we now have only core, platform and bindings. What are you speaking of? , as well as with the idea of GNOME as platform for everyone What is this and where was it proposed? . This proposal from Deja-Dup is a neat example. IMHO deja-dup is not suitable to be a core module (as per current definition of core: only stuff needed to start user session), but it's perfect as approved by GNOME module. No, we do not have any such plans to approve or disapprove of modules. If they are outside of core, platform or bindings, the only official designation is that they might be featured in our marketing. That's it. We do not bless modules any more. Also, IMHO the UI proposed changes to Deja-dup preferences are well designed for GNOME 3 experience (backup as a service, not as user launchable app). So, this seems to be a contradiction: we can't place you in core, but we don't want to provide the ability for a proper integration. Also, what about third parts, vendors and distros? That's a technical problem, not political. For instance, Ubuntu provides a really useful Additional Drivers tool and I suppose the best place for it is System Settings Hardware; same for Prey (http://preyproject.com/) and it's configuration panel. Are we going to make GNOME a closed desktop? Again, technical. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
So as the Deja Dup maintainer, life will go on when you drop support. Worst case, I can just make the panel a dialog. But dropping the existing API feels like a frustrating bait and switch. It was not clear (at least to me) that this was your intentional all along, so myself and others made plans and put effort into making panels. Maybe next time you could whitelist the plugins you want or force people to compile with -DI_PROMISE_I_AM_BLUETOOTH so that 3rd parties don't waste time. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 10 May 2011 21:51, Bastien Nocera had...@hadess.net wrote: 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. There's a separate thread for this that I replied to. 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. 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? This is a personal backup program, not something for system administrators. But I'm not opposed to improving support as long as it doesn't harm the existing personal backup experience. As for btrfs snapshots and such. I could envision adding support to duplicity to determine what changed via btrfs, but would not want to make btrfs part of the backup format itself. Duplicity's existing format design assumes very little about the backend (put, get, delete, list) so that it can support cloud destinations like Amazon S3. S3 won't be adding a btrfs in the cloud anytime soon. -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 11 May 2011 02:55, Andrew Cowie and...@operationaldynamics.com wrote: --encrypt-key 5CB48AEA \ --sign-key 5CB48AEA \ specify asymmetric encryption using my GPG key. Not supported currently. Needs design work to still be friendly for non-technical users. --volsize 100 \ implementation detail, but it should be tweakable? I've been taking the stance it shouldn't be tweakable. One thing Deja Dup does is adjust it whether you're hitting the network or not. --exclude '/home/andrew/**/*.o' \ I can tell it to ignore certain files or folders by name, but it doesn't seem I can exclude by pattern? As a developer there are an awful lot of intermediate files that I don't need to backup --exclude '/home/andrew/**/tmp/**/*.class' \ --exclude '/home/andrew/**/tmp/**/*.h' \ and so on. Can't do it. You can't even specify specific files, just folders. It needs design work: https://live.gnome.org/DejaDup/Design/Proposal-MoreThanFolders --exclude '/home/andrew/.gvfs' \ --exclude '/home/andrew/.local/share/gvfs-metadata' \ --exclude '/home/andrew/.cache' \ --exclude '**/*.cache' \ --exclude '**/Cache/**' \ If we're backing up a user's home directory, then ignoring all this stuff could just be automatic, right? .gvfs and .cache are already secretly excluded along with .thumbnails and the like (unless you specifically include them). See the help documentation for a list. I didn't know about gvfs-metadata, but if it lives in .local/share, sounds like user data that should be backed up. --exclude '/home/andrew/.gnome2/epiphany/favicon_cache' \ --exclude '/home/andrew/.local/share/Trash' \ --exclude '/home/andrew/.Trash' \ --exclude '**/sessions' \ --exclude '/home/andrew/.nautilus/metafiles' \ --exclude '/home/andrew/.nautilus/saved*' \ --exclude '/home/andrew/.fontconfig' \ Sounds like we need to file bugs against epiphany to put its cache in ~/.cache. Same for nautilus. I'll look into .fontconfig. The user's trash is in the default user-visible exclude list. Ditto. And of course doing a system level backup, we don't need (and need to forceably skip): --exclude '/dev' \ --exclude '/proc' \ --exclude '/sys' \ --exclude '/tmp' \ --exclude '/var/lock' \ --exclude '/var/run' \ --exclude '/var/cache/apt' \ --exclude '/var/lib/apt/lists' \ --exclude '/var/log' \ --exclude '/media' \ --exclude '/mnt' \ And so on. /dev, /proc/, /tmp, and /sys are excluded by secret default I believe. I don't think /media or /mnt are, but those are good suggestions. While this is clearly the sort of thing that could degenerate into a zillion configuration options and permutations, I'd like to hope GNOME's backup solution could help me out here and just Do The Right Thing™. Agreed. That's why I've taken the view that volsize and obvious cache exclusions should not be something the user should have to see. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
