Very much agreed. It’s quite a bit above my paygrade, though.
I bet there are many more people missing the familiar “Recent files” menu than are even aware of the “Favorites” menu in file panels.
In any case having it in a submenu of the “Open” item in the “File” menu makes opening a recent file much quicker (2 clicks, instead of 4, plus the mental toll of groking the file dialog popping up) and is better discoverable.
Anyway, I guess describing the topic of “Recent files” in the HIG only makes sense when the needed infrastructure is there…
I would usually go to the open dialog using command+o, and then find the file there. And it doesn’t have to stay hidden in the hard to discover Favorites menu, either, the whole filepanel could be switched between a “browse” view (as we have now) and a “recent files” one, for example.
Anyway, the recent files menu is a good idea as well, my point was just that it’s a lot easier to do this by having common code that all applications can reuse, as is already the case for the file panels. And the HIG does not need to specify how filepanels should look like and operate, since all apps reuse the already existing ones. The recent files menu should be similar to that, a ready-to-use tool to include in applications.
And these solutions are not exclusive: whenever one of them is implemented (with on-disk storage in a defined format), it will be easy to have the other one reuse the same data and present it in a different way.
Indeed. What I’d also like is another tab with a query input. Obviously when opening a file, but also useful to find the location to save a file. To look for a file you know is in the location you want to save this file in.
Maybe this could become possible when this year’s GSoC project on combining Find window + result window is finished…
I’m definitely on board with that. Having a recent-file-menu doesn’t preclude an improved file panel that also shows recent files.
Has anyone already thought about that “on-disk storage in a defined format”? Is something like sensible or just my layman’s lame idea:
Add an attribute _recentfiles (type string) to the index.
When loading/saving a file, look for that attribute, create it if it’s not there.
Read the attribute, look for your app’s signature. If it’s not there, append it to the end of the attribute plus the current time as “accesstime” (all comma-separated).
When it comes to showing recent files of an app, query for _recentfiles, see if your app’s signature is in it, if so get the accesstime after it, show the 10 files with the newest accesstime, and remove your app’s signature and accesstime from all older ones.
While typing this I began to wonder if this can be performant at all… After all, pretty much all documents will have a _recentfiles attribute and looking thru them all for your apps signature sounds costly.
Maybe queries aren’t suited here after all. What else, a Registry? /me ducks
We could call it something else and hide it in the Registrar or something…
Some filesystems have a “last accessed” timestamp hard-coded into the format. It could be used by a query but having a hard-coded limit of how many appear in the listview gadget seems unnecessary. Being able to limit the display to a directory with different sorting orders or not would be a more abstract use of the file list though. Isn’t that one of the filters that was mentioned in a ticket about queries? I seem to have read that somewhere before.
Only, we don’t need the general “last accessed” time, but the “last accessed” time of one specific application.
I’m having trouble parsing the rest of your comment: “having a hard-coded limit of how many appear in the listview gadget seems unnecessary”, you mean showing all files the app ever opened? What listview gadget?
"Being able to limit the display to a directory with different sorting orders or not would be a more abstract use of the file list though. You want the user to be able to filter the recent file list?
Limiting a query to a folder is part of the GSoC project, yes.
All that said, the “Recent files” under “Favorites” in the file panel may actually already work nicely. However I can never tell, because most of my files are on non-boot partitions and aren’t kept there between reboots…
Is anyone able to fix #10682 (Deskbar's "Recent docs/folders/apps" ignoring non-boot partitions on reboot) – Haiku ? Then we may test if the current feature of the file panel already work satisfactory and think about how they could be available to an Open-subenu directly, too.
Hmm, actually I now feel a bit dumb and need to apologize heading us into all kinds of directions. Apparently StyledEdit, as one example, already uses recent files from an Open-submenu that it doesn’t have to do anything to manage:
BMenuItem* openItem = new BMenuItem(BRecentFilesList::NewFileListMenu(
B_TRANSLATE("Open" B_UTF8_ELLIPSIS), NULL, NULL, be_app, 9, true,
NULL, APP_SIGNATURE), new BMessage(MENU_OPEN));
That’s what @PulkoMandy has been saying from the start… Sorry again.
I’ll just add that to the HIG then…
As the API actually prides “recent files” features, the HIG text can be shorter and simpler. Improvements on the recent file handling should be directed to the API and its implementation.
This is the text I plan to submit:
Easy Access to Recently Used Files
The Deskbar provides the most recently used documents, folders and applications, but those lists are limited in slots (defaults to 10) and not permanent. Therefore, applications that deal with files should provide the user with a list of files they have opened or saved most recently.
It’s recommended to show the last 10 opened or saved files in a submenu of the Open menu item in the File menu. If the user clicks the Open label, the regular file dialog appears, otherwise they can choose the file to open from its submenu. An example of this is the StyledEdit application.
The Haiku API provides BRecentFilesList::NewFileListMenu() in the RecentItems.h header that creates the recent files menu and has the system do all its management.
