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



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.

>> 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.

>> 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...

> 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.


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.

-mt




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]