Re: [Deja-dup-hackers] Report for June 6 - June 20, reply to Michael Terry

[Urban Škudnik <urban skudnik gmail com>]

Hey,

On Jun 26, 2010, at 7:59 PM, Michael Terry wrote:

> As usual, I have been super slow in responding, sorry!
>
> On 21 June 2010 13:05, Urban Škudnik <urban skudnik gmail com> wrote:
> >  * Decide what to do with files that are in subdirectories of the  
> > directory
> > in which we are running command - do we want to show files that  
> > were deleted
> > in subdirectories as well? Do we only show subdirectory if entire
> > subdirectory was deleted?
>
> Don't bother with subdirectories for the 'missing files' view.  The
> partial restore feature will let the user browse.
>
> > http://dl.dropbox.com/u/1493539/p2.png
>
> For the summary, look at how I show the 'files to restore' in
> AssistantRestore.vala.  It does a nice label list of files, without
> showing the whole path.  The whole path isn't needed because the
> operation is already context-sensitive for a directory.

Ok, will do. As for removing whole path - check. ;)

> > > We aren't currently using libgee.  Does your work add a dependency  
> > > on it?
> >
> > Erm, yup. Is this a problem?
>
> I'd prefer to avoid it if I could.  It's not a blocker, but would be
> nice not to add more libraries.  If you're only using it in one place,
> maybe it could be refactored?  If it's all over the place, I wouldn't
> bother rewriting your code.

Hm, I think I use it in a number of locations now. I'll take a look at  
documentation of GLib to see if things are easily replaceable.

> > > I like your UI mockups for the file-oriented view!  But I wouldn't
> > > worry about presenting files that have merely changed in the  
> > > nautilus
> > > plugin.  Just show the deleted files (ala your
> > > http://dl.dropbox.com/u/1493539/restorefiles.png).  If they want
> > > changed files, they can already right click on existing files in the
> > > nautilus UI and revert them.  This 'missing-files' mode is for the  
> > > 'I
> > > need to get that file I deleted last week back!' use case.
> >
> > Yup, I agree. I would however add a comment regarding existing UI for
> > revering files. At the moment we only show user when they deleted  
> > the file.
> > I believe we can and must do much better with this since users will  
> > mainly
> > access DD from Nautilus in the future (well, at least that is how I  
> > would
> > like they do ;).
>
> We only show when they deleted the file?  We should show all backup
> dates, not just the last one...

Sorry, my bad. Yes, we show dates of all backups.

> > What we could do is show them the difference that they made in each  
> > revision
> > that we have and maybe offer to restore the file to a different  
> > location. I
> > haven't yet made any mockups so I'll just do a short summary:
> > Basically on one side we would show a list of dates on which file was
> > changed and on the right an entire file with things that were (with  
> > respect
> > to existing version?) deleted shown in red (or crossed over) and  
> > things that
> > were added as green or bold. An idea that also crossed my mind but  
> > I don't
> > know how doable it is, is that one could read ODF and Word (man can  
> > have a
> > dream, can't he? ;)) files and see changes for that as well.
>
> :)  My gut reaction is that we don't need to show the whole file in
> place.  There may be performance issues, and frankly they probably
> don't need it all that often.  I could totally see adding a 'open'
> option though to examine a file.  Some 'diff' functionality would be
> interesting but not something I've worried about yet.   I think Time
> Machine does that?  Would be curious to see how they show it.

Showing the whole file in place by default is probably unnecessary and  
"open" option is probably a valid solution (although to streamline the  
interface, showing at the very start current version and when older  
versions come in showing those (older) versions would be nice so that  
user would see how file changed over time). As for performance issues  
- since we would only retrieve a single file a number of times I don't  
think this should be a problem, especially if we use incremental  
loading and load older versions as data comes in.

Time machine basically shows you directory as it was on a certain date  
(a week ago, a month or two ago, etc.) and you can open file as it was  
on that date - there is no diff. Adding it could help user a lot since  
it would be much quicker for him to notice the changes that he made  
(and that's basically the rationale why we should implement it).

> I'll also respond to Matej's idea in this email:
> His mockup is more like what I was thinking of for the 'partial
> restore' functionality.  I prefer just showing files in the contextual
> directory for the 'missing files' feature.

Hm, yes, I didn't think of that. It would probably be worth thinking  
how best to incorporate partial restore, file history and directory  
history... If I understand partial restore correctly, this  
functionality would basically be achieved by showing directories and  
offering to restore directory and all of its subdirectories and files  
(if user activates directory history at "high enough" level)?

Or did I miss something about partial restore?

Cheers,
Urban

> -mt