GNOME.org
 

Re: [Deja-dup-hackers] Use of GtkIconView


On Jun 26, 2010, at 8:12 PM, Michael Terry wrote:


These are interesting ideas.  My initial thought when thinking about
the feature was that we would make it a two-step process.  First pick
the files, then pick the date at which you wanted to restore them
(this would be tricky because they mightn't all be around at the same
time).
This is doable, but picking a date is a bit tricky also because users probably won't recall when they changed file unless we give them some options of when file was changed (and even that doesn't necessarily guarantee that they will remember). 



In which case, the default would be 'last time we saw them' or
something.  And then the user could instead choose dates and we would
take the closest version of the file to that date.

That is simplest from a UI perspective, and that's probably why I had
that in mind.
I would say that going with last version is the way to go for restoring and if user wants to see all version he can then check version history. This is of course a problem if he wants to restore to a different location as we don't have any history for new path. At the moment I have no idea how to resolve this (simply not support restoring to different location doesn't quite satisfies me). 



Your ideas are certainly snazzier.  But I'm not sure how your UI
handles a file that was in all the backups (but obviously is no longer
in the directory).  Do you show it in all time points?  Do you just
show the most recent version?  Or a file that was in the first 3
backups, then missing for 4, then showed up again in the most recent
backup?
Nope, I just show the most recent version. As for how to handle a file that was in some backups, then disappeared and reappeared in another backup - I would simply switch to AssistantRestore for this.
Basic idea would then go like this (if we use option b - iconview with an overlay that shows time span): We would first list files that are currently in directory and after them would start to add files that were deleted based on last seen ordering. If user would want to take a look at history of a file, he would select a file (either current or deleted) and select "show history" which would run AssistantRestore for that particular file.
This removes the trouble of complicating the basic view and makes a clear distinction between modes of operation (directory history vs. revert to previous version).
A thing I didn't think of before - IconView pushes us in the direction of file manager (which is a good thing in my opinion). Unfortunately it seems that we can't just write a custom view for Nautilus that would show files that were deleted as some kind of "virtual files" (for lack of better term) without physically creating them (creating them and deleting them when we close DD seems a bit of a hack?) which means we have to use Gtk.IconView and integration with Nautilus will probably have to end at context item (which is a bummer in my opinion). 

Cheers,
Urban



-mt

On 22 June 2010 16:06, Urban Škudnik <urban skudnik gmail com> wrote:
Michael suggested that I look into Gtk.IconView so here is a bit of research 
into it.


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.
Yes, I agree that using icons is a must and will implement that in any case.
As for Gtk.IconView - technically it doesn't seem much more complicated (at least by some samples that I saw - I haven't actually programmed anything with it). It is based on the same MVC principal that TreeView is based upon 
so it probably also wouldn't be much more work.
However, things get a lot more complicated if we want to give user some kind of time perspective at backup. For this I came up with three suggestions 
(ordered by assumed increasing difficulty).

Mockups for 2) and 3): http://dl.dropbox.com/u/1493539/iconviewsuggs.png
1) We simply add time difference at the end of file name (e.g. filename.txt (Yesterday), filename2.pdf (Two months ago)). Seems quite clumsy and users 
probably wouldn't notice time diff very quickly.
2) We use standard IconView but show time span with a (transparent) overlay at bottom/middle of the screen that shows time range of files that we have currently shown in window. I am not sure if there is already Gtk component for this - if it is, it's relatively simple, otherwise I would probably need to make custom widget (this one seems easier to make in comparison to 3.). 

3) We use custom scroll component (kind-of based on time machine -
http://km.support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT1427/TM%20Restore.png)
that shows time points on regular intervals. When user scrolls we show more 
time points for more detailed overview (if needed). We would also
encapsulate time points between which we are currently displaying deleted 
files with gray area.
The last suggestion seems to be quite time consuming since I would need to 
develop quite complex custom widget.
Probably the optimal solution (if we use IconView) would, at least for now, 
be 2.

As always, thoughts and suggestions warmly welcomed ;)

Regards,
Urban
P.S. I forgot to draw "Restore" button - that would probably be put at the bottom of the window (if I wouldn't use existing cancel/forward buttons that 
Assistant has)

_______________________________________________
Mailing list: https://launchpad.net/~deja-dup-hackers
Post to     : deja-dup-hackers lists launchpad net
Unsubscribe : https://launchpad.net/~deja-dup-hackers
More help   : https://help.launchpad.net/ListHelp
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]