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

For a start - my apology for not writing a report for previous week. On Sunday my work done until that point seemed very trivial to write about since I was stuck with an issue (getting list-files-directory -t=N) and I decided to give it two more days and hopefully resolve it - I only finally resolved the issue on Wednesday and at that time writing a report seemed a waste of effort since in a few more days entire task could be mainly resolved. A good thing about it was that I got a lot better picture of how DD operates internally - I never thought that signals were used so much (and that they are as useful as they are!). I guess this is the result of too much work with web model.

If such a show-stopper occurs again and I don't write the report by Monday and you wonder why, feel free to bug me (and maybe give a hand with suggestions ;))

Anyway, the executive summary:
TIME SPENT: Previous week between 25 and 30, this week 35

HIGHLIGHTS: Finished all technical issues of restoring files (going through history, getting list of files in directory, several bugs) that were deleted
from directory and therefore mainly finished AssistantDirectoryHistory.

Exactly what kind of user experience we want. I found out it can be quite tricky
to get things working in precisely the way I imagined it and I find myself
using shortcuts too often (and of course do it "the right way" when I catch myself).

Since I am almost finished with first GSOC task I currently have no other major concerns.

Nope. I would, however, greatly appreciate additional feedback regarding user interface.

I was stuck for a lot of time at how to implement my own operation and how to issue orders to it in appropriate manner multiple times. Issue is now resolved.

 * Found PriorityQueue for queuing duplicity which proved to be quite reliable and worked as a charm
 * Finished OperationFiles that is used for calling list-current-files
 * Finished AssistantDirectoryHistory - still missing is actually calling OperationRestore
 * Polish user interface and user interface

 * Found Vala bug (or at least a missing warning) - https://bugzilla.gnome.org/show_bug.cgi?id=622119
 * Drew myself nice flowcharts of Deja Dup's execution cycle which I plan to digitize and write appropriate documentation about

 * 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?
 * Pass selected files to OperationRestore and do actual restore
 * Discuss with my mentor how do we want to proceed. What to polish, to which extent (and not loose too much time on details that can be resolved later on) and whether or not I should take on something else.


Currently implemented interface:


Since I will now start adding finishing touches (pretty names for files, maybe actually search - now it doesn't work, showing user how far back in history we are, show time difference instead of actually time of deletion/last seen, etc.) I would like to get as much feedback about user interface that we want as possible.

Another issue is also should I offer user only an option to restore to previous location or should I also enable restore to some other location?

I am also in debt to Michael since I haven't replied to his reply to my last report:

After losing a lot of time I found some help on #vala and
managed to figure out that we weren't including gmodule-2.0 and that even
though --pkg gmodule-2.0 was added to VALA_CFLAGS it still has to be added
to configure.ac (PKG_CHECK_MODULES). This also showed me that our build
system is a bit more trickier then I previously thought.

Huh, good find.  Send me a tiny patch?

It is included in my branch (https://code.launchpad.net/~urbans/deja-dup/deja-dup.nautilus) - or do you want just the diff for this? Personally I don't see the need for including it into main branch now since no code relies on this and it should be enough if you include it when you will merge my .nautilus branch to main branch.

I was also surprised that similar problem occurred with Gee since I was
expecting that we were using it's helper functions already.

We aren't currently using libgee.  Does your work add a dependency on it?

Erm, yup. Is this a problem?

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

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.

You mentioned concerns about the speed of the operation.  I agree the
'finding all missing files' interaction with duplicity will be slow.
I think the UI should be responsive and fill out incrementally while
this is going on, while indicating that it's thinking (maybe a
judicious GtkSpinner).  At any point the user should be able to choose
missing files and continue to restore them before the 'get all files'
operation is done.

Yup, as things are coded right now, I add things as they come in and I cancel OperationFiles if user moves forward.

I assume it would be vastly more work, but an icon/grid view like
nautilus's would be nifty too.  Could you look at that, and how much
of that work GtkIconView would take care of for us?  If it's a giant
task, we could do that in a later cycle if we wanted.

One nice thing about an icon view would be nice big file icons based
on filename (gio has a function for this).  In fact, even if we don't
use an icon view, we should probably show tiny file icons in the list
view.  Anyway, it's a thought.

Haven't looked it up, but I will. But I suspect it will turn out to be quite more complicated. Will try to do demo...

The idea of a search box is a good one.  But I'd say work on getting
it to work fine without a search box and we can work on a search box
as an add-on after we nail down the main view, since they seem
technically independent.  Hopefully the '1000s of files' use case is
not terribly common anyway.

I added it to user interface but haven't programed it yet. Will do so if we keep current view and after I polish other things.

Thoughts? Ideas? Suggestions? ;)


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