Re: Recently Used Files Proposal

[Luis Villa <luis villa gmail com>]

On 6/3/05, Emmanuele Bassi <ebassi gmail com> wrote:
> Hi,
> 
> On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:
> 
> > > A menu would never give enough informations on the recently used
> > > items: apart from an icon associated to the mime type, we won't know
> > > their location, or when they were accessed; so, given that we should
> > > provide a tooltip for each item (with an API for adding custom text,
> > > maybe), a menu could be also implemented.
> > >
> >
> > Emmanuele, really the best way to provide access to recent items in
> > application is menu.
> 
> Even if I could agree, I'm still skeptical about this.  A menu is what
> it is used on some platforms, but I don't know if it's indeed the best
> way to provide all the data we need to know about a recently used
> resource.

You're thinking this way, I'd suggest, because your use cases are
overly complicated. Consider this ridiculously common use case:

* I want to open a file that I know I saved in the recent past.

That's it. Very simple, very common. Currently, I can open one menu
(Places->Recent Documents) and 'solve' that user problem.

Covering that use case is the whole point of every recent file menu on
every OS. People don't care what month it was opened, or what day it
was opened, they just know that they opened it in the recent past, and
they want to open it again without digging into crappy FS heirarchies.
Covering the more complex user problems is nice, but if you make it
too hard to solve this very basic need, you've defeated the point for
most users.

Luis




 
> Consider web browsing; Firefox, Epiphany, Internet Explorer - all show
> the history as a side pane containing a treeview, with each page that
> has been visited put it into a treeview.
> 
> What I am suggesting basically is creating the concept of a "resource
> history", showing what resources the user has recently openend; and if
> the panel registered the menu items it launches, we could also have the
> recently used applications, for instance.
> 
> >  The main idea of recent file is to allow open new
> > file without dialog, while you suggestion is to replace one complex
> > dialog (FileChooser) with another one (RecentChooser).
> 
> The idea is to offer a set of widgets - a dialog, a button, whatever -
> in order to access this data.
> 
> The GtkFileChooser could register an item in save mode, and show the
> recently used items in open mode, so we could scrap the entire "Open
> recent..." menu item altogether, and just use the "Open..." menuitem; it
> could be a viable solution.  But this does not mean that we should not
> provide some other way to access this data.
> 
> Kind regards,
>  Emmanuele.
> 
> 
> 
> --
> Emmanuele Bassi <ebassi gmail com>
> Web site: http://log.emmanuelebassi.net
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>