I've seen a lot of reports of user confusion about this and answered a number of questions about it myself. There's also a bug report in which people requested the feature, not knowing that it already exists: Bug 72665.
We should consider surfacing this setting in a more obvious place.
I agree we want to do something.
But it's also important that we expose toggling on a per activity basis, which wouldn't be trivial.
As a counter to moving the setting, the other plausible option is changing the UI of recent documents to have some visual hint that it's activity aware. (recent documents for activity "Default")
This would both expose the feature of activities and hint at the setting location at the same time.
Personally I think instead of shoving the existence of activities in the user's face, we should just make everything activity-aware. Right now it's not at all obvious what's activity-aware and what's not, which I think contributes to the feature being kind of... weird.
Alternatively, I know it would be kind of redundant, but maybe we could expose the config UI in multiple places: one in an easily-located part of System Settings, and again in the Activities KCM. The easily-located one would just show the settings for the current activity.
"we should just make everything activity-aware" if it just were that easy ;)
(In reply to Nate Graham from comment #2)
> Alternatively, I know it would be kind of redundant, but maybe we could
> expose the config UI in multiple places: one in an easily-located part of
> System Settings, and again in the Activities KCM. The easily-located one
> would just show the settings for the current activity.
The more I think about it, the more I think this imperfect solution may be the way to go. Attempts to teach users about activities over the years have failed due to the feature's scope being unclear and difficult to explain, and the bugginess of the implementation.
If we collected a few toggles related to privacy, we could have a 'privacy centre' item in the system tray. For example:
- disable usage tracking for the current activity
- forget recent usage history
- allow network searches in KRunner
I don't see another plausible solution - putting a 'forget' menu into everything that shows recents, plus a button somewhere close to allow discretely 'forgetting' (https://bugs.kde.org/show_bug.cgi?id=353229) would be quite a UI problem.
> and the bugginess of the implementation.
Almost all bugs we have had over the years (since plasma 4 days) are due to people storing non-normalized URIs in KA or changing format of the URIs between versions thinking KA will magically know that konsole, applications:Konsole, applications:/Konsole.desktop.whatever, /usr/share/...desktop are the same thing.
I was thinking of changing the API to force the user to set the allowed URI format before allowing reporting URIs, but that would just make it more difficult to make mistakes, not impossible.
I'd make it a KCM, but a "Security & Privacy" KCM would be a good idea IMO.
I propose to move the PrivacyTab to a full fledge KCM and rename it to Recent Files.
While it is privacy sensitive, but the features there are just easier to find by Recent Files keyword than Privacy.
We can keep the keyword, and we could make this KCM appear somewhere else also, splitting it from activities kcm is a first step.
(In reply to Méven Car from comment #7)
> I propose to move the PrivacyTab to a full fledge KCM and rename it to
> Recent Files.
I would also add some kind of control that allows choosing whether the configuration affects all activities (+ apps that are not aware of activities) or only the selected (in the KCM) activity to kee the current functionality. I would also add some notice, at least to the activity-specific config, something like “Not all applications will respect these settings.”. There is a lot of apps that simply do not respect that.
*** Bug 319738 has been marked as a duplicate of this bug. ***
*** Bug 72665 has been marked as a duplicate of this bug. ***
*** Bug 435325 has been marked as a duplicate of this bug. ***
*** Bug 423732 has been marked as a duplicate of this bug. ***
Git commit ee931882a05a55031ca92937dd147658e0e79a37 by Méven Car.
Committed on 23/07/2022 at 10:08.
Pushed by ngraham into branch 'master'.
Add a Recent Files kcm to manage file history settings
M +1 -0 kcms/CMakeLists.txt
A +231 -0 kcms/recentFiles/BlacklistedApplicationsModel.cpp [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +57 -0 kcms/recentFiles/BlacklistedApplicationsModel.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +89 -0 kcms/recentFiles/CMakeLists.txt
A +4 -0 kcms/recentFiles/Messages.sh
A +21 -0 kcms/recentFiles/common/dbus/common.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +21 -0 kcms/recentFiles/common/dbus/org.kde.ActivityManager.Features.xml
A +41 -0 kcms/recentFiles/common/dbus/org.kde.ActivityManager.ResourceScoring.xml
A +12 -0 kcms/recentFiles/definitions.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +27 -0 kcms/recentFiles/kactivitymanagerd_plugins_settings.kcfg
A +6 -0 kcms/recentFiles/kactivitymanagerd_plugins_settings.kcfgc
A +16 -0 kcms/recentFiles/kactivitymanagerd_settings.kcfg
A +5 -0 kcms/recentFiles/kactivitymanagerd_settings.kcfgc
A +165 -0 kcms/recentFiles/kcm_recentFiles.cpp [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +7 -0 kcms/recentFiles/kcm_recentFiles.desktop
A +58 -0 kcms/recentFiles/kcm_recentFiles.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +16 -0 kcms/recentFiles/kcm_recentFiles.json
A +78 -0 kcms/recentFiles/qml/recentFiles/BlacklistApplicationView.qml [License: GPL(v2.0+)]
A +6 -0 kcms/recentFiles/recentFiles-kcm-features.h.cmake
A +169 -0 kcms/recentFiles/ui/RecentFiles.ui
A +91 -0 kcms/recentFiles/utils/continue_with.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +41 -0 kcms/recentFiles/utils/d_ptr.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +43 -0 kcms/recentFiles/utils/d_ptr_implementation.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]
A +69 -0 kcms/recentFiles/utils/optional_view.h [License: GPL(3+eV) GPL(v3.0) GPL(v2.0)]