If I am not completely mistaken, the Haiku API offers a standard way to maintain recent files via the registrar. These are persistent across reboots, and are also shown in the Deskbar. If you want to provide such options in your application (which you should IMO), you can just tell registrar to give you that list filtered by those your application supports. That’s all there since Be. Since it’s already centralized, you can clear the history for all applications at a single point.
Personally, I like the overloaded “Open” menu: you can directly click on it or use its shortcut, but it has a submenu containing the recent files. I’m not fond of clobbering the file menu with this as found on other platforms. I’m not sure, however, if the registrar supports clearing only your application’s files from this list yet. In any case, IIRC, only accessible files are returned, while non-accessible ones are preserved to be available when you plug in your USB stick again.
Besides #10682 (Deskbar's "Recent docs/folders/apps" ignoring non-boot partitions on reboot) – Haiku , there must be some policy that auto-clears the “Recent lists”. Otherwise it would be a huge list after a few months.
Good to get back on-topic, discussing the details of the HIG addition, not implementation. 
Is the app supposed to show all recently opened files of all filetypes the app supports, or just the files recently opened/saved by this app? For example, I browse through 20 images with ShowImage. Should the image editor app show all those? That would flush out the files that were actually opened/saved by the editor app before…
Yeah, the overloaded “Open” menu is quite nice. Maybe the HIG should advise to always do it like that. It saves an item in the “File” menu and is consistent (not one app showing 4 files directly under “File”, others more under “Open recent”).
I’m not yet sure about showing unavailable files. ArtPaint does italicize those files. But currently, in my ArtPaint, all unavailable files are actually deleted. So in that case, those entry should be removed for good. Maybe the app could check if the volume of the file is actually mounted, and if it is, conclude that the file is probably deleted.
If I understood well, the problem of OP is that at the moment only available files are shown. An user might be interested to see in the list a recently opened file that is not available but could be if the volume was mounted. In this case, the file name should be greyed and a tooltip could show the file path to give an hint of the volume/device to mount
This topic is a more general discussion, because there isn’t yet any info on “MRU” in the HIG. We try to come up with a consensus where to put that list, if it’s needed (given Deskbar and file dialogs offer something like this already), and how to deal with currently not-available files (either moved/deleted or on a network resource or unmounted USB device etc.).
There are no tooltips for menu items AFAIK.
There are several ways to deal with currently not available files.
- simply remove them from the MRU list
- keep them in the internal list in case they become available again, but don’t show them in the GUI, as Axel thinks he remembers Deskbar/Registrar handles it.
- show the item in the MRU as greyed-out or italic. Choosing the not-available item could try to mount the volume and just open the file if possible, and throw an alert if it isn’t. Maybe something like:
The file 'path/to/file' could not be found.
It may be on a currently not available volume, or was deleted or moved.
[Remove from menu] [Cancel]
(Not quite happy with the label ‘Remove from menu’…)
There may be more alternatives…
It is good that on Deskbar, you only see what’s available now.
In an app that I didn’t use for a while, I’m glad to know where I put my mess last time. LOL
I think there the menu list shouldn’t exceed five entries. Either you clean it all or new items will replaced the old ones.
For items not currently available, if the path is found but not the file, we are in moved/suppressed case and it shouldn’t appear at all. If the path is child of a known mount point and the device is identified and present just not mounted (think of a data partition) the file should shown be in italic. If the path is on a removal media then file should be shown greyed. No interaction should be possible for a greyed entry, for italic entry just post an alert saying ‘Sorry, that file is located on ‘volume_name’ which is currently unmounted. Please try again after mounting it.’
I thought about another thing. What happens if, as suggested, the user mounts the volume leaving the app opened.
Since the app was left opened, we can reasonably suspect that the user mounted the volume with the intention to access to that file.
Obviously, if the file is there, the menu should refresh and and show it now as a valid entry.
But, if the file is not found making the entry disappear doesn’t seem a good option. In this particular case, a suppressed/moved file should appear perhaps with a strike to let the user know that the search has been done. Of course on app restart, that entry will disappear like for other suppressed/moved file.
I’d say, if a file was on a currently mounted volume but isn’t there anymore, it’s resonable to simply remove the item from the MRU list (internal and GUI).
If the file was on a currently not mounted volume, show it greyed-out. Node-monitor for mount/unmount. If it becomes available again after its volume gets mounted, “un-grey” it. And vice-versa.
I’ve written an addition to the HIG that can be discussed before I submit it to Gerrit. After writing most of what was discussed here, I came up with a simpler version that I like better. The start for both versions are the same:
Easy Access to Recently Used Files
The Deskbar provides the most recently used documents, folders and applications,
but those lists are limited in slots 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.In case of identical file names in different locations, include the middle-
truncated paths in the item label.The last entry in the Open submenu should be “Clear” beneath a separator that
clears all entries from the submenu.
Then comes either of two versions. First, mostly of what was discussed in this topic:
Version A
When building the list of recent documents, each entry has to be checked if
the file is actually available. It could be moved, deleted or on a removable or
currently unmounted volume. The application should keep an ‘internal’ list of
recently opened/saved files from which the entries of currently not available
files are not removed, in case they become available again. This ‘internal’
list is separate from the list of files that are displayed as menu items in the
Open submenu.The Open submenu should show files that are currently not available as disabled
(grayed out). Those are files whose paths suggest they are on a currently unmounted
volume. The application can node-monitor for newly un/mounted volumes and update
the menu accordingly.Files that appear to be deleted or moved, should be removed from the ‘internal’
list and Open submenu. These are files that are supposed to be on currently mounted
volumes, but are not at their expected location.
Or, what I’d prefer, because it’s simpler:
Version 2:
Files may have been moved, deleted or are on a removable or currently unmounted
volume. When a file was chosen from the Open submenu and it’s not at the expected
location, the user should be prompted with an alert: “The file ‘{/path/to/file}’
could not be found. It may be on an unmounted or removable volume, or renamed or
deleted. Do you want to query for it?”. Button 1: “Cancel”, button 2: “Query file”.
Option 1 will just close the alert. Option 2 will script Tracker to query for the
file name and file type and close the alert.The application should node-monitor for newly un/mounted volumes and update
the menu accordingly.
I like version 2 better. No greyed out menu items that the user will wonder what they mean.
If a file isn’t found, the user is told so, given the hint it may be on an unmounted volume. The user may just cancel, mount the volume and try again. Or they may remember moving the file somewhere and take the app’s offer to have a query for it, whose result may be drag’n’dropped into the app.
“Dead” files sooner or later drop off the list on their own.
I doubt that making it more complicated will find many devs willing to hop through all those hoops…
Opinions?
Bit late to the party but…
“#18737 ([registrar] List of recent Docs/Folders/Apps seems to grow indefinitely.) – Haiku” was fixed 6 months ago.
I think that applications should not implement such functionality themselves because recently opened files are already displayed in Deskbar. Why duplicate functionality ans reinvent the wheel in each application?
Most other systems have both a global recent file list and one per application.
Consider this use case: You open your photo editing software of choice and want to continue editing the last file you edited with it, but the recent documents list of the OS is clogged with the 200 holiday pictures you looked through in another program.
Or say you haven’t used your music notation program for a month and all your recent documents on the OS list are tax documents in some office format.
As was mentioned above:
I’d personally prefer version 1 since they allow an experienced user to spot the problem without additional clicks and interactions, but I agree that version 2 seems a lot simpler to implement and a bit friendlier to new users.
The complexity of implementing Version 1 would probably require the OS to provide some utility functions so not every application developer has to deal with node monitoring and so on.
Having to have an internal list of files (based on file locations) Is already too complicated for me as an application developer, what I’d want instead is a querry for files with the flag they have been opened my my app recently. and nothing more.
Not sure what the alert in version 2 serves? A file not beeing available is unrecoverable. If the recent list is constructed with a querry it would not make sense to re-querry for the file.
There might be a situation where a file is re-generated, such as in the case of a log file or part of an automated process, such as the output of a software build. Or data that is polled from some server or device, then deleted and re-created when the task runs again.
Probably too much of an edge case to be relevant for most applications though.
Disclaimer: Because of being a non native English speaker, I may have misinterpreted or missed something
Why not both solutions?
Recent items could be shown with a similar menu:
Availables
File1.cpp
file_2
Missing
File copia di 3.txt
Recoverable
File.old.jpg
…
If an unreachable item was previously on an already mounted volume, it belongs in the missing section; selecting that file alerts the user to its absence, i.e., that it may have been renamed or moved, and asks if they want to remove the item from the list or to query the file (via its size? or its hash?).
If the missing item is on an unmounted volume instead, it belongs to the recoverable section; clicking on this item alerts the user that the volume is not currently mounted and asks if they want to mount it now or remove the item from the list.
These sections are intended to be smart: if there are no items that meet those criteria, the relevant section is not shown
Speaking of recent items, I would like to propose another feature that I think could be useful: being able to open recent files/folders with another application other than the default/preferred application.
EDIT [moving it to a new thread]
Either way, the chosen way needs to be fast enough so that the user doesn´t need to wait for the program to search files, find which are there, which have disappeared, etc.
So I believe the menu option for Recent Opened Files could be a little far from the Open option, so that people who will search for the file they want do not need to deal with this list, or avoid it if said list just “pops up” when moving the mouse around the Open option.
One very common case for this - at least for developing folks - is when doing git checkouts or switching branches. Files get re-written removing all attributes…
It’s ot necessarily unrecoverale. The user is made aware that the file’s path isn’t available, and they may facepalm and think “right, it’s on USB-stick No. 5” or “right, it’s on the unmounted partition X” and mount those, and everything works. Or they remember they’ve moved them and query for it.
Possibly a good idea, though of course only working on BFS volumes and breaking for the git-scenario described above.
But before diving into the specifics here (does every app just add their tracking attribute to the index of every volume? Is it nice to have every app slap their attribute on files they opened? Would the index pollute over time with the remains of uninstalled apps’ attributes left behind?)
Did I/we overthink the issue as far as the HIG is concerned? Should the HIG be as detailed and go into implementation specifics?
Or should it just say: use a “Open” submenu for 10 recent apps and make sure to deal with no longer available files (by removing them/informing the user/etc.)?
To be honest, “Version 1” alone is already very complicated. Too complicated for my and nephele’s taste, at least, and I bet most other developers. Making it even more complicated may result in perfection (though I doubt everyone will agree), but if the perfection never leaves the HIG, because nobody is motivated to write all the code needed for actual applications, it’s no use…
Worthy of discussion. Could you open a new thread for that?
If the goal is to have the same behavior in all applications, it would be better to provide some utility class or function in Haiku to implement it. Then everyone will reuse that, because it’s simpler than reimplementing it.
That’s why in the previous discussion I suggested to do it in the Favorites menu of file panels: any improvement there (such as making the list persistent in one way or another) immediately benefits all existing applications. Making a new common code is the next best thing (all applications have to be adjusted to use it, but it’s a relatively simple change that can be copied over).
If you ask each application to implement this on their own, you will get a lot of slightly different and incompatible interpretations of it.