the real reasons are:

 * performance
 * user interface
 * API and widget hierarchy

the bit about "pain to implement" referred to the preliminary design of the widgetry.


* performance

making the creation of the entire File menu dependent on the recent files list could take too much time and ruin the overall user experience, especially if the coe tries to be "smart", and check if a document exists before displaying it.  that's the reason more meta-data was required to register a new recent document in the first place.

* user interface

I believe that the HIG is wrong about the placement of the recent documents list inlined, considering the limits it imposes on the list itself (no more than four/five items).  the OS X approach, that is using a sub menu, is far more clean and useful, since it allows applications to have longer lists of recently used documents and additional items, like a "more..." item.  it also maps more cleanly the behaviour of the panel, which shows a "Recent Documents" menu item.

* API and widget hierarchy

there is no clean way to add a list of menu items inside a GtkMenu but using a GObject, which is completely alien to the widget hierarchy.  the other problem is that a UIManager action cannot create a list of items without changing the GtkAction class.

but this is more a user interface problem: I don't believe the inline list is really good.  I'd like to hear what the usability team has to say on this issue - I know that there has been a discussion some years ago about this, but GNOME did not have a clean recent documents API at the time.

(goes without saying: if GtkAction can be changed to support multiple widgets then I'd add inlined support in menus created using UIManager - barring usability review, obviously)

hmm, this is going to be a problem if it hinders EggRecent users to port to GtkRecent in time for Gnome 2.16. 

If we can reach some consensus in GNOME that the submenu is better (among the HIG guys, for instance), then this is OK by me.

I agree that if the HIG mandates the use of a submenu I'd be willing to change.

However *personally* I prefer the inlined menu since accessing a recent file is supposed to be a fast shortcut and it's handy to have it just one mouse click away. More importantly the inlined menu allows to open a recent file from the keyboard simply with Alt+F+1,2,3,...

> the inlined menu allows to open a recent file from the keyboard

if the HIG changes I expect it will mandate a) the name of the recent documents menu item and b) its mnemonic key; using a default mnemonic for the "Open Recent" menu item and gtk_recent_chooser_menu_set_show_numbers() you'll then have Alt+F+<key>+1, 2, 3, ... - just one key more.

sorry for the spam, Cc-ing usability-maint as I'd like a word from them

Has there been any progress on a usability decision this past year and half?  GTK+ still doesn't have an easy way of inlining the menu, so it's a pain to use the new hotness code while being HIG-compliant.

*** Bug 511418 has been marked as a duplicate of this bug. ***

copied from bug 511418 (I'm duping it to this, because this bug report has the usability keyword, if any of the usability team is actually using it).

just to add a couple of thoughts about this:

- EggRecentViewGtk in libegg/recent-files was how the old recent files code did
the inline (and sub) menu; it's clunky, and it's a Object, not a GtkWidget; it
can be reworked, anyway, to get a RecentChooserInlineMenu widget, attaching
menu items to a GtkMenu at a given position. it might not be the best solution,
though; most menus should be created using GtkUIManager or GtkBuilder (or
both).

- the UIManager object doing the inline thinghie (RecentViewUIManager) is
equally clunky, but at least it could probably reworked into a
RecentActionInline, using placeholders. another option is to make GtkAction be
able to return a list of menu /toolbar items, which would in theory be more
interesting (also useful to use a single GtkAction class to create a radio
button group).

- there is code for a GtkAction generating an inline list of recent files
inside a UIManager-generated menu at:

  http://www.gnome.org/~ebassi/recent-uimanager-inline.c

it's what gedit and other applications have been using, so it might be a good
starting point for a GtkRecentInlineAction.

as I said on the mailing list, I'd gladly review a patch for a GtkRecentInlineAction. I'd really like to have an assessment from the usability-team as well.

From a usability point of view, I think having recent files in the "File" menu at all is the wrong approach, whether inline *or* as a submenu.

This is for two reasons. First, it discourages habituation: it requires you to think about whether the file you want is likely to be in the N most recent files, before you even start the gesture to open the file. If you think it will be in the N most recent, you'll open "File" > "Open Recent". If you think it won't be, you'll choose "File" > "Open...", or just press Ctrl+O. In either case, you could be wrong (especially if the file is close to the Nth most recent), and if you are wrong, you've wasted several seconds. An inline section of the "File" menu would be *slightly* less bad in that the file might catch your eye before you finish choosing "File" > "Open..." -- but still, if you see it a millisecond too late (or if you instinctively pressed Ctrl+O instead), you'll be stuck with the Open dialog.

Second, it inevitably leads to applications implementing "Open Recent" inconsistently -- some not at all, some as a submenu, and some (if this change goes ahead) inline.

I would rather recent files were presented in the Open dialog, as one of three ways to find the file you want -- by hierarchy, by history, and by search. That way, (a) people could safely form a Ctrl+O habit, without worrying about the recency of the file they wanted; (b) the list of recent files could be hundreds long, grouped by day, instead of being limited to a precarious dozen or so; (c) *every* application that uses the GTK filepicker would get the Recent Files feature, with hardly any effort; and (d) in *every* application it would behave the same way.

That's a good idea, but the "Recently Used" bookmark in the file chooser will show me 3 files, which is sub-par. I filed bug 514260 about it.

I don't see a problem with moving to the submenu approach here.  GIMP has been doing this for a while and it seems to work out well.

It'll allow you to increase the number of items listed but I'd suggest only doubling it to 10 or so; however constants like this are always up for discussion.

I would also suggest that there is a final menu item for [[More Recent Files...]] and if possible even listing the number beyond what is shown [[More Recent Files... (##)]].  This menu item should open the File Dialog to the recent files; which provides a scrollable and search(able) full list of files.  This way when scanning the list people can continue searching for a recent file they didn't see listed in the menu.  "More Recent Files" might not be the best wording, please offer suggestions.

Required ASCII Art of submenu:
-----------------------------
|                           |
| (loop 10 recent files)    |
|                           |
----------------------------|
| More Recent Files... (##) |
-----------------------------

I'm one of those who enjoy recognizing the file I'm looking for before clicking on Open in the File menu, so I like inline recents.  But your proposals provides another alternative with comparable performance.  Would be great to have.

the recently used location in the file chooser is already available, it probably needs some minor tweaks, also coupled with the usage of GIO in both the recent manager and the file chooser.

the second proposal is perfectly implementable using the current GtkRecentChooserMenu and adding a menu item directly inside the widget (and controlled by a property); something like:

  gtk_recent_chooser_menu_set_more_item_label (menu, "Give Me More Recent Files...");
  gtk_recent_chooser_menu_set_show_more_item (menu, TRUE);

and a GtkRecentChooserMenu::more-item-activated signal. the file chooser cannot start directly in recent files mode at the moment, so a GTK_FILE_CHOOSER_ACTION_RECENTLY_USED action should be added (and possibly a GTK_FILE_CHOOSER_ACTION_SEARCH, to start in search mode); as an alternative, the default more-item-activated handler could create a GtkRecentChooserDialog, which would only show the recently used files and not a full file selector.

Eight years on, and nothing happened — except that we kind of stopped using menus.