Re: Dealing with the trash

> >  * Someone wants to restore something that they just deleted.
> >  * Someone wants to restore something that they deleted a while ago.
> > 
> > In the first case, a Date Deleted column is entirely sufficient. 
> Well, I find myself using that view all the time when looking for
> something I deleted today or yesterday, in a trash that hasn't been
> emptied for a year and is bursting. I find clicking on "today" much
> easier and faster than to actually have to locate, read, and mentally
> parse "Do 06 May 2010 14:12:52 CEST" in a timestamp column in a list of
> thousands of elements.

Date/time formats need to be improved. There is a bug for that and it is
planned to be worked on, afaik. That will make using a Date Deleted
column much easier.

A user's knowledge of when a file was deleted will become increasingly
fussy and unreliable the further back in time you go. Once you go back
further than a week or so (that's a estimation ;) ), searching by other
criteria (like file name or content) will become the best way to locate
the desired file.

Another way to find a file that was deleted a while ago would be to
utilise contextual data. Hooking into the activity journal could be
something to explore in this regard.

> > The interface you've suggested [1] adds a lot of complexity. We should
> > try and use the parts of the interface that are already there, rather
> > than piling on new stuff.
> Actually, it removes many UI elements and thus visual clutter, because
> it limits what the list view displays. Sure, it adds a few text strings
> with simple words as "today", "yesterday", "x days ago", but at the
> same time it lets you get rid of thousands of list entries, each one
> with multiple complicated columns.

It's the additional scroll bars, non-standard list functionality and
layout that I would count as additional complexity, not additional list

> But maybe that's just me. I am totally fine with my external python
> script solution that gives me that display. It doesn't have to go into
> Nautilus if my use patterns are a minority oppinion. Thanks for
> commenting, anyways.

Don't be discouraged! This is valuable and necessary work, and it's
great that you're tackling the issue. The current extension certainly
isn't sufficient - this has to become a part of Nautilus itself. We need
to be rigorous about the UI, is all, and I'd query the need for an
additional filter.

Anybody else got any opinions on this?

IRC: aday on

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