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.

Please note that any check of file availability will potentially hang the checking thread for up to a minute, if that file happens to be on a network share. Please no automatic checks in recent file lists.

We discussed the topic in the design meeting.

We agree with the use case: Some users might value privacy over convenience and expect unavailable documents to be removed from the MRU by default. But since many if not the majority of users prefer the current solution, we recommend to add a toggle to the start center "[ ] Automatically remove unavailable documents" and run the function on start, for example.

Furthermore it could be beneficial to disable those menu items in the MRU that refer to unavailable files.

This might be an easy hack. Code pointer: sfx2/uiconfig/ui/startcenter.ui, RecentDocsView::clearUnavailableFiles(), SfxViewFrame::Notify()

(In reply to Mike Kaganski from comment #10)
> Please note that any check of file availability will potentially hang the
> checking thread for up to a minute, if that file happens to be on a network
> share. Please no automatic checks in recent file lists.

True, let's add a dependency.

(In reply to Heiko Tietze from comment #12)
> (In reply to Mike Kaganski from comment #10)
> > Please note that any check of file availability will potentially hang the
> > checking thread for up to a minute, if that file happens to be on a network
> > share. Please no automatic checks in recent file lists.
> 
> True, let's add a dependency.

Meaning a UI option to opt-out, with some tooltip to explain its use?

(In reply to V Stuart Foote from comment #13)
> Meaning a UI option to opt-out, with some tooltip to explain its use?

I vote for opt-in since most users prefer convenience and consistency over ultimate privacy. And the tooltip should not be necessary.

Just to be clear about my usecase: for me personally the concern is not privacy, but rather efficiency, by:

* reducing information overload from non-existent deleted/moved documents
* having more "slots" for "real/relevant contents" in the recent items list

I can imagine that if that process were to take a long time on some computers, it could be done in a non-blocking thread in the background (I don't understand why it should block the UI main thread or something like that?) every now and then, a while after startup (ex: once every few 1-3 days or something?) if an autoclean checkbox is enabled in that menu.

If you really really really don't want that non-blocking-background-thread approach, then I guess the middleground is having a manual "Clear Unavailable Files" action in that recent files menu, just above (or below) the "Clear List" menu action... just so that the user doesn't *need* to launch the LibreOffice general non-app-specific dashboard to access such an action (and many users might not even know or remember that it exists anyway). In that case, that action should simply be present in that menu by default in each app, no need for an option for it to be present or not...

As extra convenience, you could even offer to do the batch clearing (of non-existent files) with a button in the error dialog that shows up when the user tries to open a nonexistent file from the recent items menu. That way, it lessens the frustration of clicking a file, ending up in a dead-end dialog, needing to click to dismiss the dialog, and then clicking a couple more times elsewhere to remove the nonexistent files.