deja-dup-hackers team mailing list archive
-
deja-dup-hackers team
-
Mailing list archive
-
Message #00062
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.
CONCERNS:
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.
WAITING ITEMS:
Nope. I would, however, greatly appreciate additional feedback
regarding user interface.
STALLED TASKS:
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.
ACCOMPLISHMENTS:
* 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
MINOR TASKS:
* 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
ACTIONS FOR FOLLOWING WEEK:
* 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:
http://dl.dropbox.com/u/1493539/p1.png
http://dl.dropbox.com/u/1493539/p2.png
----
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? ;)
Regards,
Urban
Follow ups