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

[Michael Terry <mike mterry name>]

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

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.

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?

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