Bug 402790 - When a KCM is opened directly, show it in System Settings rather than KCMShell
Summary: When a KCM is opened directly, show it in System Settings rather than KCMShell
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
: 405028 410169 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-01-02 15:37 UTC by Claudius Ellsel
Modified: 2020-05-31 21:27 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.19.0


Attachments
Systemsettings (91.04 KB, image/png)
2019-01-02 15:37 UTC, Claudius Ellsel
Details
Standalone (49.59 KB, image/png)
2019-01-02 15:37 UTC, Claudius Ellsel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claudius Ellsel 2019-01-02 15:37:00 UTC
Created attachment 117241 [details]
Systemsettings

As already written on https://phabricator.kde.org/T10247:

When using system settings it has a list with the different sections and subsections. Example attached.

However when searching for a specific setting like the mouse setting from start menu the application launches as standalone, see attachment.

Is there a reason for this behaviour?

From UX perspective I had expected that the normal system settings page opens (similar to GNOME and Windows).
Comment 1 Claudius Ellsel 2019-01-02 15:37:36 UTC
Created attachment 117242 [details]
Standalone
Comment 2 David Edmundson 2019-01-02 16:35:16 UTC
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.
Comment 3 Claudius Ellsel 2019-01-03 15:19:09 UTC
(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.
Comment 4 Claudius Ellsel 2019-01-16 13:34:54 UTC
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.
Comment 5 David Edmundson 2019-01-16 13:52:47 UTC
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.
Comment 6 Claudius Ellsel 2019-01-19 14:21:25 UTC
(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.
Comment 7 David Edmundson 2019-01-19 14:35:22 UTC
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.
Comment 8 Claudius Ellsel 2019-01-19 18:19:07 UTC
(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?
Comment 9 Christoph Feck 2019-03-24 12:50:52 UTC
*** Bug 405028 has been marked as a duplicate of this bug. ***
Comment 10 dagobertram 2019-03-24 19:25:04 UTC
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? ;)
Comment 11 Nate Graham 2019-07-25 13:26:01 UTC
*** Bug 410169 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2019-07-25 13:27:01 UTC
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.
Comment 13 Claudius Ellsel 2020-02-20 09:47:21 UTC
(In reply to Nate Graham from comment #12)

Any news about this?
Comment 14 Marco Martin 2020-05-11 08:41:55 UTC
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
Comment 15 felipe antonio 2020-05-31 14:48:46 UTC
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.
Comment 16 Nate Graham 2020-05-31 15:58:36 UTC
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.
Comment 17 Claudius Ellsel 2020-05-31 21:27:43 UTC
(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?