With the Start center, there is a hamburger button, when you can select to Clear Unavailable Files.

Thanks for the suggestion, but:

1) I don't use the "start center" global application, I launch individual apps
(ex: Writer, Calc) directly, as on Linux they're readily available as app launchers.
There is no such action available within individual applications.

2) I shouldn't have to manually "take out the recycling bin" of non-existent files.
The computer knows in an instant they are non-existent, so it should do that for me.
Asking the user to do this is giving them what's presented in this article:
https://zachholman.com/posts/shit-work/ (no offense meant)

Documents on a volatile medium such as USB are not always available. We cannot just ignore it, and that's why bug 101302 introduced the manual clear method. => NAB

And I disagree with adding this function to the module's file menu (or similar places).

Yep, even with individual app launchers and by-passing the StartCenter, behavior after handling of bug 101302 ('Clear Unavailable Files' on the SC 'Actions' hamburger-button) is sufficient for majority of use cases. 

User explicitly selecting to clear any items from the MRU history, via the SC.

But, it might be nice for non-SC users to implement a Tools -> Options configuration to expose the same menu entry to the main File -> Recent Documents submenu.

Maybe position it on the Options -> General panel, in the Open/Save Dialogs block?

Seems easy hackable...

I understand the usecase for removable USB devices and such… can't LibreOffice automatically figure out the difference between a local vs removable (or networked) device? It could run a check on the presence or absence of the parent root filesystem (ex: if the whole F drive is missing on Windows, or if the path is from /run or something like that on Linux), or if it needs to go through a USB flatpak portal to access the file, etc.).?

(In reply to Jeff Fortin Tam from comment #5)
> I understand the usecase for removable USB devices and such… 
> ...

We work against what the os/DE reports as available in the current LibreOffice session [1] Then simply test DirectoryHelper::fileExists() against mounts/remotes FS that have been exposed as available. 

Then optionally dropping with RecentDocsView::clearUnavailableFiles() [2] action available now from the SC UI for those document URLs that are not, but done by explicit user action.  User option of adding the control to the File -> Recent Documents sub-menu is reasonable.

Why would we want to make it more complicated that that, crossplatform LibreOffice is not a FileManager. Onus is on user or os/DE to restore the FS mounts? Not something required of LibreOffice to track.

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/include/comphelper/DirectoryHelper.hxx
https://opengrok.libreoffice.org/xref/core/comphelper/source/misc/DirectoryHelper.cxx
[2] https://opengrok.libreoffice.org/xref/core/sfx2/source/control/recentdocsview.cxx?r=b77ad21d445783d77697470796be5c43f9fc5cd3#190

> Onus is on user or os/DE to restore the FS mounts?

In my as-reported description, I personally am not in the usecase where the filesystem comes in and out of existence. I am dealing with local filesystem files have been deleted / moved away, they don't exist anymore, they will never come back in that exact spot, and I shouldn't have to baby-sit the office suite app to tell it that my local filesystem's deleted files were deleted, because it can check that automatically for me.

By saying I understand the USB usecase, I'm just going the extra mile to try to accomodate _your_ usecase, even though I have some doubts about how common it is and whether it's actually critically needed to maintain history of recent files from hotplugged "external media" (i.e.: it would really not the end of the world for me if those files were purged from the recent documents list automatically, because whenever I plug a USB drive, the file manager will automatically open it in front of me and show me its contents, from which I can open a file directly).


> Not something required of LibreOffice to track.

It is, if you want the app to provide a smart humanized UX instead of cluttering the view with counterproductively stale results (instead of keeping those limited numbered slots dedicated to actual existing files) and expecting users to manually manage their filesystem in an office suite "in addition to managing it in their file manager". I shouldn't have to do the work in two places.

In other words, I'm trying to advocate for LibreOffice to present more relevant "current" results rather than stale non-actionable ones.

A concession/tradeoff I can make here is: if you really really really don't want to remove the non-existent-files results automatically, then they should at least be grayed out so that "offline/vanished" files are visually different and my eyes can ignore the grayed-out ones, to spot the actually relevant ones more easily... but that doesn't provide the advantage of being able to "free those spots" in the list for more actually-existing results.

(In reply to Jeff Fortin Tam from comment #7)
> ...

> It is, if you want the app to provide a smart humanized UX instead of
> cluttering the view with counterproductively stale results (instead of
> keeping those limited numbered slots dedicated to actual existing files) and
> expecting users to manually manage their filesystem in an office suite "in
> addition to managing it in their file manager". I shouldn't have to do the
> work in two places.
> 
> In other words, I'm trying to advocate for LibreOffice to present more
> relevant "current" results rather than stale non-actionable ones.
> 
> A concession/tradeoff I can make here is: if you really really really don't
> want to remove the non-existent-files results automatically, then they
> should at least be grayed out so that "offline/vanished" files are visually
> different and my eyes can ignore the grayed-out ones, to spot the actually
> relevant ones more easily... but that doesn't provide the advantage of being
> able to "free those spots" in the list for more actually-existing results.

By that you are suggesting major cross platform changes to the File -> Recent Documents MRU document listing. In both its forms: the menu items listing of what is held in the LO user profile (registrymodifications.xcu), and also of the MRU's graphical representation via the SC backing window's Thumbnail views, to be able to suppress them graphically in the UI.

Doing so for what is frankly a marginal use case.

So No! It would be more appropriate to simply apply the clearUnavailableFiles() action by default, and deal with complaints over missing recents for the missing deleted, or URLs of removable and remote FS mounts.

But my recommendation remains the less expensive and more likely easy-hack of providing Option to expose the Clear Unavailable action on the File -> Recent Documents menu to make it available from any module with no dependence on the Start Center's UI. The User then having the option of clearing any deleted or non-mounted URLs from the MRU history.

(In reply to V Stuart Foote from comment #4)
> But, it might be nice for non-SC users to implement a Tools -> Options
> configuration to expose the same menu entry to the main File -> Recent
> Documents submenu.
We could make the function a UNO command and allow users to customize it into the menu.