Re: Recently Used Files Proposal

[Emmanuele Bassi <ebassi gmail com>]

Hi,

On Wed, 2005-06-08 at 00:37 -0500, Federico Mena Quintero wrote:
> On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
> 
> > I've spoken with Federico at GUADEC about the recently used files
> > handling, and we came up with some ideas for improving the current
> > situation.
> 
> I must say that the huge delay at the crappy restaurant in front of the
> conference center certainly helped us in terms of having enough time for
> our discussion :)

We *definitely* should have stealed/broken something... :-)

> > I've attached a prototype API for GtkRecentItem and GtkRecentManager
> > (already set to live in libegg, for the time being). Let me know what
> > you think of it.
> 
> This looks very good!  I have a few minor comments about the API, which
> I'll post tomorrow if I have time.  In the meantime, I sketched out a
> list of requirements here:
> 
> 	http://live.gnome.org/RecentFilesAndBookmarks
> 
> [I moved the old content to a sub-page, for reference.]

Saw it, but interspersed commenting on the wiki is ugly.  I'll comment
here.

+++

Do we need timestamps for both "last visited" and "last modified"? Isn't
one of them enough? 
        
Short answer: XBEL needs them. :-)
Long answer: "modified" and "visited" are semantically different; a
"recently used" applet should just update the "visited" attribute when
it launches an item, and not the "modified" attribute, which would be
modified when an application register itself or when a group is added or
when the visibility flag is changed.

              * Are the timestamps for the recent item itself, or the
                item they point to? (The time the file on disk was
                created vs. the time the recent item entry was
                created.) 

The "added", "modified" and "visited" timestamps pertain just to the
item; the "timestamp" attribute is used when an application registers
the item.  A "mtime" attribute for the resource pointed by the item
would require another metadata field.

              * When an item can be modified by others as well, the
                distinction would enable to answer the question "Has
                this item changed since I last looked at it?" 

      * Is "number of times accessed" a single property, or is it
        per-application? 

I started with a per-item property, but then switched to a
per-application one, since it would enable a finer-grained filtering and
sorting.

      * Do we need the private flag? What uses it currently? 

Short answer: nobody uses it, but we should keep it.
Long answer: visibility on a per-registration or per-group system would
be tricky; the "Private" flags is just an hint for viewers: it says
"this item should not be visible if you did not register it, or if you
do not belong to any of the groups in it".  Viewers might decide to show
it anyway, but at user option.

      * Icons. This is somewhat up to the caller, I think, as it can
        just call gnome_thumbnail_factory_lookup() on an item's URI. If
        the thumbnail is missing, it can simply use the icon
        corresponding to the item's MIME type. For GtkFileChooser in
        particular, the file chooser will certainly call
        gtk_file_system_render_icon() internally, which uses an abstract
        GtkFilePath (which is, in effect, a URI). 

Agree.
        
      * Get notification when the items change. 

This would require something inside Gtk to check for changes without
poll()-ing each URI every N milliseconds;  inotify could be the answer,
but Gtk does not depend on it yet.  So I think that this should go into
a platform library, which uses the list from RecentManager and monitors
each item inside it for changes on the resource pointed by the URI.

Need a way to populate the "recently used" part of the File menu. 
        
              * EggRecentViewGtk lets you specify a GtkMenuItem after
                which the items will be inserted 

EggRecentViewGtk is brain damaged: it should be wiped out with fire and
medieval tools.  What we need is a subclass from GtkMenu, to be attached
as a submenu to an 'Open Recent...' stock menu item; this would make
adding items to it painless.

Something like this:

  GtkWidget *r_item;
  GtkWidget *r_submenu;
  GtkRecentFilter *filter;
  
  /* filter on the tuple:
   *   (<mime type>, <application name>, <application group>)
   */
  filter = gtk_recent_filter_new ();
  gtk_recent_filter_add_mime_type (filter, application_mime);
  gtk_recent_filter_add_application (filter, application_name);
  gtk_recent_filter_add_group (filter, application_group);
  
  r_item = gtk_image_menu_item_new_from_stock (GTK_STOCK_OPEN_RECENT,
NULL);
  r_submenu = gtk_recent_chooser_menu_new ();
  
  /* filter and sort the recently used files submenu */
  gtk_recent_chooser_set_sort_type (GTK_RECENT_CHOOSER (r_submenu),
GTK_RECENT_SORT_MRU);
  gtk_recent_chooset_set_filter (GTK_RECENT_CHOOSER (r_submenu),
filter);

  /* this fires every time a menu item containing a recent item is
   * activated; the callback signature would be:
   *
   * void callback (GtkWidget     *recent_menu,
   *                GtkRecentItem *recent_item,
   *                gpointer       user_data);
   * 
   * and it basically should resolve in launching another instance
   * of "application" with the URI provided by recent_item.
   */
  g_signal_connect (G_OBJECT (r_submenu), "recent-activate",
                    G_CALLBACK (on_recent_activate), NULL);
  
  gtk_menu_item_set_submenu (GTK_MENU_ITEM (r_item), r_submenu);

+++

> As to your Perl mockup --- do we need such a megawidget inside GTK+?  I
> think it would only be necessary if we wanted the main way in apps to
> access the recent files to be through such a dialog.  However, if we put
> this in the desktop itself (Nautilus or the Panel?), then it should not
> be inside GTK+.  I wouldn't worry about it too much right now, except
> for sketching out how it would actually use the proposed API to see if
> the API makes sense.

The UI-side is what worries me the least: every widget we choose could
really live everywhere we want.  The core functionality, on the other
hand is tricky.

Nevertheless, we should provide some way to do this in a consistent way
- for instance a Menu widget or a TreeView-like widget.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <ebassi gmail com>
Web site: http://log.emmanuelebassi.net