Summary: | When a KCM is opened directly, show it in System Settings rather than KCMShell | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Claudius Ellsel <claudius.ellsel> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | antonio.unix, bugseforuns, claudius.ellsel, dagobertram, kde, midenok+kdebugs, nate |
Priority: | NOR | Keywords: | usability |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/plasma-workspace/e67e8d6d92a1b85e85be1f8f656ff5b51bd90ace | Version Fixed In: | 5.19.0 |
Sentry Crash Report: | |||
Attachments: |
Systemsettings
Standalone |
Description
Claudius Ellsel
2019-01-02 15:37:00 UTC
Created attachment 117242 [details]
Standalone
There are two approaches to finding data. Searching and browsing. If you've already searched, you don't need to browse. There's no point listing anything when we can just show what's relevant. You've not stated what problem changing this would fix. (In reply to David Edmundson from comment #2) > There are two approaches to finding data. Searching and browsing. > > If you've already searched, you don't need to browse. There's no point > listing anything when we can just show what's relevant. > > You've not stated what problem changing this would fix. This would fix the problem of confusion. If there is a general systemsettings application with categories then it might be useful to also open it in every case a part of it is invoked for consistency. This way the user can learn the context. Else he might not be sure that it is the same application that appears in systemsettings. However it seems that the systemsettings application itself consists of many standalone applications which only get aggregated there, correct? I guess this is different for GNOME settings or the Windows settings application. I don't consider this resolved. If this is not the right place to discuss this, I am also willing to discuss it elsewhere. However then I'd like to have the relevant parties on board as discussing this without them is rather pointless. This is the right place to discuss it. The relevant parties all see this bug tracker.
>> You've not stated what problem changing this would fix.
This remains the case.
A user doesn't need to know where it is in system settings if they know how to invoke it from their preferred context point. It's not solving a problem.
(In reply to David Edmundson from comment #5) > This is the right place to discuss it. The relevant parties all see this bug > tracker. Good to hear. So why close this issue before finishing the discussion? > >> You've not stated what problem changing this would fix. > > This remains the case. If you took a look at my comment on this: (In reply to Claudius Ellsel from comment #3) > This would fix the problem of confusion. [...] It fixes the problem of being inconsistent and behaving unexpectedly. Being unexpected in itself isn't a bug. We're not trying to make a 1:1 clone of anything. Some behaviour is new or different. That doesn't automatically make it worse. I don't buy the arguments presented here so far, and we can't agree with every user piece of feedback, sorry. (In reply to David Edmundson from comment #7) > Being unexpected in itself isn't a bug. > > We're not trying to make a 1:1 clone of anything. Some behaviour is new or > different. That doesn't automatically make it worse. > > I don't buy the arguments presented here so far, and we can't agree with > every user piece of feedback, sorry. I did not call it a bug and agree that this is not a bug, but rather a feature request. Also I don't expect you to clone 1:1 anything. I can agree, if you say the pros are more important than my cons, but I think there are cons. Two more: - When opening lets say bluetooth settings from search, connecting a speaker, I cannot use menu to go to speaker settings afterwards. So I cannot use search to open a specific setting and later go to another setting from the menu. - Different look&feel of the settings Another rather neutral argument: - If you have the space available, why not use it? *** Bug 405028 has been marked as a duplicate of this bug. *** I would also like to see the behavior Claudius Ellsel was describing. For me it is confusing when I search for a setting via krunner and don't get it right the first time. Because then I have to search once more or open up System Settings to look for the right setting. Also, if I found the right setting with a tool like krunner, I would now see in which category I have to look for, when I open System Settings the next time. If the (one) settings application behaves the same each time, it is easier for me to learn how to use it properly, instead of dealing with System Settings and multiple little settings applications. Does that make any sense? ;) *** Bug 410169 has been marked as a duplicate of this bug. *** We discussed this at the Plasma/Usability & Productivity sprint. Unfortunately I don't seem to have written any notes regarding our conclusions but IIRC we decided to revisit this. (In reply to Nate Graham from comment #12) Any news about this? Git commit e67e8d6d92a1b85e85be1f8f656ff5b51bd90ace by Marco Martin. Committed on 11/05/2020 at 08:41. Pushed by mart into branch 'master'. force systemsettings for kcms Summary: as we can't kill completely kcmshell just yet, hack intothe services runner to replace on the fly the exec line of the service to systemsettings FIXED-IN: 5.19.0 Test Plan: search and launch directly for a module, systemsettings is launched wit hthe proper module loaded Reviewers: #plasma, ngraham Reviewed By: ngraham Subscribers: broulik, ngraham, davidre, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D29157 M +16 -1 runners/services/servicerunner.cpp https://commits.kde.org/plasma-workspace/e67e8d6d92a1b85e85be1f8f656ff5b51bd90ace I agree with the comment of (David Edmundson comment # 2) There are two approaches to get where you want, the user himself should be able to choose which way he prefers, and not kill a resource that I think is unique !. It is a resource that fascinates me, and that I would not like to see out. Please don't re-open bugs because you disagree with the outcome. If you prefer the old behavior, please explain why and what is worse for you about the new behavior. (In reply to felipe antonio from comment #15) First, just to be clear: It should still be able to discuss this matter here, but the issue should stay closed. To the topic: Also to clarify: Neither way for a user to get to the desired setting is removed. It is just that one way is modified slightly for more consistency. You can of course still search for a setting, but now the whole settings app opens on the related page instead of opening a small settings window without context. Reasons why this might be beneficial were listed in the comments. So there is nothing killed. If this clarifications are irrelevant to your point, I'd be interested in why you think the change is bad. What exactly did you find unique and fascinating about the "old" way? |