Re: [Deja-dup-hackers] Partial restore, take 2

[Allan Day <allanpday gmail com>]

> > The design seems to be heading in the right direction, though it still
> > seems overly complex. This could do with a proper design person (ie.  
> > not
> > me ;) ) to have a look at it. I do have a few ideas though - I'll try
> > and get something together to show soon. Until then, some general
> > observations/comments...
> >
> > * Nautilus integration would be great. It should be possible to access
> > previous versions of a file or directory from the file browser.
> 
> As far as I got with my research, this is quite hard. To do this we  
> would need to show files that don't exist (any more) and as far as I  
> understood it's API for extensions this is not possible - you can only  
> use files that are already there.
> 
> That said, implementation of this would be possible if we would a make  
> a patch for Nautilus or make this integral part of Nautilus, which  
> could take a lot of time. If this is highly desired I might do some  
> research in this direction. This then of course offers high degree of  
> integration but also brings other problems (demanding, release cycle  
> become linked to Nautilus, ...) but offers other rewards.
> 
> If this is what we want I have no problem of doing appropriate  
> research and work (for a start I pinged one of Nautilus hackers but  
> haven't got his response yet).

Thanks for the mail about that. Want to send it to the Nautilus mailing
list?

> > * It would be nice to be able to open and copy from backups as well as
> > restore.
> 
> I'm not quite sure what you mean by this? If I understand you  
> correctly this is what we want to achieve with this feature? ;)

I meant that you should be able to open and copy files from the restore
window. But yes, I think we agree on this.

> > * Restoration should be undoable - ie. a backup should be done as part
> > of the restoration process. Restorations should be marked in the  
> > restore
> > UI.
> 
> Undoable how

Through the normal backup/restore facilities. You make a backup before
each restore.

> > * Users will probably be interested in seeing the changes between
> > backups. Is it technically feasible to display this kind of  
> > information
> > (either as diffs, number or size of changes) in the UI?
> 
> Yes, but only on request, otherwise it is too slow. Basically we need  
> to restore all versions for which user is interested in, restore them  
> to temporary location, display diffs and only after user selects the  
> version that he would like to restore that we actually copy from /tmp  
> to original location. How to implement diffs into all this requires a  
> bit more thought.

OK.

> >> I've got some comments below for this v2 mockup.  It's a nice and
> >> flashy mockup overall.
> >>
> >> 1) I'm not sure how the "select a date range" option works either as
> >> you try to enter one or visually after you select one.
> 
> You either click on calender and select a specific date or you slide  
> back (we mark the most interesting dates). Later on I got the idea of  
> using a separate mark on the top (http://dl.dropbox.com/u/1493539/marked-above.png 
>   with "tuki" replaced by date in production version of course) that  
> would show the date of backup that user selected (and remove the input  
> fields for date and only leave small calender button if user really  
> want specific date selection.
> 
> >
> > Yes, we can probably come up with a better widget for this. I've got a
> > few ideas here.
> 
> Well, the idea is that we have a slider that is configured depending  
> on how far from first backup we are. First two options are "hard  
> coded" (latest revision and last backup) since they represent probably  
> the most interesting feature for our users. To give users a hint that  
> they can slide back in time, it would probably also be good to include  
> another "hard coded" version "First backup".
> 
> Gtk.Scale seems nice but is not quite what I want (because it fills  
> itself from start value) - a widget that would not fill itself and  
> still offer a mark at current value would be a better option. For now,  
> to keep things simple, I kept the Gtk.Scale (see http://dl.dropbox.com/u/1493539/marked-above.png 
>   for how it looks).

Horizontal sliders aren't good for usability, particularly when they're
long. Also, what about when backups haven't been made on a regular
basis? That wouldn't map onto a slider, would it?

> >> 2) You probably don't need two buttons for "Queue directory" and
> >> "Queue file".  For example, what would happen if you selected a
> >> directory?  Which button would you press?  The GTK+ file dialog
> >> handles this by choosing the current directory if no files are
> >> selected or otherwise choosing the files or folders selected.
> >
> > Is it necessary to queue then restore? I suspect that it generally
> > isn't, and that it adds unnecessary complication when a single or  
> > small
> > number of selections are being restored.
> 
> It is unnecessary when you have a single file yes, but on the other  
> hand if user wants to restore multiple files from different  
> directories (and possibly different dates) he would need to rerun the  
> wizard for each directory and/or date.

Why is a wizard necessary? The only necessary steps that I can see are:

1. Select a bunch of files, press restore
2. Ask for confirmation
3. Restore - show a progress window

> Other solution would be to add some kind of drag and drop solution so  
> that user would drag files to nautilus directory to which he would  
> like to restore. I haven't done any research in this direction, it  
> might be interesting, it might be confusing.

No, that would be great. :)

> > Are there any similar interfaces that we could look at for  
> > inspiration?
> 
> The simplest of them would be arguably be Time Machine for OS X, on  
> Linux there is Back in Time (http://backintime.le-web.org/), Time  
> Vault (https://wiki.ubuntu.com/TimeVault) and FlyBack (http://flyback-project.org/ 
> ). My personal opinion is that none of Linux programs resolved the  
> issue quite satisfactory enough (after all, that was one of the  
> reasons why I applied for GSOC with this project ;)).
> 
> Time machine has a slider for going back in time and does restore by  
> selecting a file and, IIRC, pushing a restore button.
> 
> Back in Time seems to offer a large list of snapshots with which you  
> browser to desired snapshot, select the file(s) and click restore  
> button.

Thanks - these are useful. I'm working on some mockups... should have
something to show pretty soon.

Allan
-- 
Jabber: allanpday AT gmail.com
IRC: aday on irc.gnome.org
Blog: http://afaikblog.wordpress.com/