Re: [Deja-dup-hackers] Weekly report (May 31 - June 6), suggestions

[Michael Terry <mike mterry name>]

Thanks, Urban!  Comments below.

On 8 June 2010 09:11, Urban Škudnik <urban skudnik gmail com> wrote:
::snips throughout::
> 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?

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

> ACCOMPLISHMENTS:
>  * Drew first user interface in Glade and connect it to existing code base
> [1]
>  * Got signals working properly
>  * Began implementing my own OperationFiles

Great!

> For now I designed two suggestions [3], basic distinction between them is
> that first is file oriented and second one is time oriented.
>
> First is similar to my existing draft [1] - first are show files that were
> deleted and then changes for each file in directory. With green I marked
> that the file was selected for restore, yellow is that it was changed and
> red is that it was deleted (should any coloring be used in actual program is
> another questions - with lots of files this could give some visual feedback
> to user. Getting all teletubbies with UI is of course not very useful...).

My vision was much more in line with the file-oriented view.  I think
users are going to be in the 'gotta get my presentation back!' mode
rather than 'gotta get all files I lost on the 16th!' mode.

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.

I'm not a huge fan of relying much on color.  People with disabilities
have difficulty with it, color means different things in different
cultures, and it makes the UI look busy.  If we can do this without
adding color, so much the better.  Since I'd prefer to drop the
'changed files' view, that would also remove its use anyway.

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.

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.

> Both can however have problem if there are a lot of files in the directory,
> which is a problem that I have no idea how to tackle other than with a
> search box.

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.


Great work.
-mt