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


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.

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



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