+1

I understand the motivation here, and it's worth entertaining as a thought experiment, but I think as-is it has problems.

• I think the "a System Settings window open on that screen configures that screen" is pretty confusing. It's inconsistent with how most of System Settings works - e.g. the display KCM. And what should happen when the user moves the window to another screen? This all gets pretty confusing and messy fast.
• A big plus to accessing configuration for a widget from the widget is that there's a clear spatial link to the thing you're configuring. I understand your System Settings entry point might be an addition to the per-widget one that opens System Settings, but as a standalone piece of UI I think that "list all the widgets" KCM would be rather unloved and confusing.
• Sort of a follow-up to the last point: Consider the case of multiple widgets of the same type (e.g. several sticky notes).

What could work a little better is a hybrid: Single master config dialogs per-panel and per-containment that list all widgets in a given panel or on a given desktop. Still needs solving the config<>which-widget mental mapping problem somehow (for a panel a visual cue could work, for the desktop where the dialog might obscure the widget it's rather more difficult) and is rather awkward for some things (e.g. spacers) though.

In T11094#188663, @hein wrote:

• I think the "a System Settings window open on that screen configures that screen" is pretty confusing. It's inconsistent with how most of System Settings works - e.g. the display KCM. And what should happen when the user moves the window to another screen? This all gets pretty confusing and messy fast.

It was just a thought; the thing in System Settings could itself have a chooser for the instances in different activities and instead. I think it's worth keeping in mind that the common case is one screen and one activity. For the majority of our users, the configuration UI would be very simple. It would need to accommodate advanced use cases, but the simple one-screen-one-activity use case would be by far the most common one.

• A big plus to accessing configuration for a widget from the widget is that there's a clear spatial link to the thing you're configuring. I understand your System Settings entry point might be an addition to the per-widget one that opens System Settings, but as a standalone piece of UI I think that "list all the widgets" KCM would be rather unloved and confusing.

Right, it would be a second point of entry. I think you're right about the spatial link between the widget and its settings, but again this requires understanding that Plasma is made of widgets, and it requires right-clicking or knowing about one of the obscure non-right-click-based paths to the widget's settings window.

To use a real-world example, I got my wife to use KDE Neon and she's quite happy with it. She uses System Settings easily enough, as it's a familiar interface. But she couldn't find how to change the wallpaper until I showed her how (it never occurred to her to right-click on the desktop, and when I provided that suggestion, it never occurred to her that "Configure Desktop" lead to the wallpaper; she didn't associate the desktop itself with the wallpaper). And I haven't yet taught her that Plasma is made of widgets so she hasn't discovered any of the configurability in the panel widgets.

• Sort of a follow-up to the last point: Consider the case of multiple widgets of the same type (e.g. several sticky notes).

That's true, that would be problematic.

What could work a little better is a hybrid: Single master config dialogs per-panel and per-containment that list all widgets in a given panel or on a given desktop. Still needs solving the config<>which-widget mental mapping problem somehow (for a panel a visual cue could work, for the desktop where the dialog might obscure the widget it's rather more difficult) and is rather awkward for some things (e.g. spacers) though.

Yeah, that could work too. My primary concern is that this config UI--whatever it is--be accessible by a standard method, e.g. from System Settings. If the only way to get to it requires right-clicking the panel or entering panel edit mode, or pressing-and-holding anything, or interacting with the Desktop Toolbox, then I don't think it offers much of an improvement over the status quo.

In the hybrid approach, we can also get more ambitious than a widget list: System Settings could totally have a minimap version of your entire system that shows the screens with panels and a little config icon on each element that brings up the respective master dialog. The part shown in SysSe can get a little more free form if it doesn't have to show every widget.

Or an alternative-but-similar KCM variant closer to your original suggestion but retaining the spatial binning is a minimap in which you click on the panel or desktop, and then you get a list with the widgets below. This might also do a good job teaching the widget metaphor BTW.

The following text has become longer than I intended to. I will put it somewhere else if it is seen as off-topic. I have been thinking about this for a while and I want to get it out there because I think it might be a solution to multiple problems.

When a KCM is opened directly, open it in System Settings rather than in KCMshell.

+1. I think in general and in most if not all cases this is the right approach

In T11094#188663, @hein wrote:

• I think the "a System Settings window open on that screen configures that screen" is pretty confusing. It's inconsistent with how most of System Settings works - e.g. the display KCM. And what should happen when the user moves the window to another screen? This all gets pretty confusing and messy fast.

I agree. I'll try to describe a way this might be solvable.

With these changes, there would always be a way for you to see all the settings for all your widgets in one place, and that place is the same place where you also find all your other systemwide settings: in the System Settings app.

In my opinion it is wrong to focus this discussion purely on widget configuration when one of the basic problems is that the distinction between widgets and other parts of Plasma isn't obvious to users (like you have already said). This is why the distinction between configuration of a widget and other kinds of configuring Plasma seem in some cases arbitrary (see 2,3,4 below). Furthermore the configuration of a widget might in many cases better be solved by switching to another widget.
I am sorry for further increasing the scope of this discussion here but I don't think this should be looked at as a standalone problem.

I'll try to list some knowledge that is necessary to not only configure widgets but to more broadly change the arrangement of the widgets, panels and their contents.

1. knowledge about what can even be changed (the answer is "most things" but the user doesn't necessarily know that)
2. an understanding of general use of what is called widgets in plasma and how they relate to panels. Furthermore at what point one widget ends and the next one begins. Some users will not quite grasp the differences between a task manager and a system tray (it can be an arbitrary distinction after all) or if the sound settings are part of the system tray, or the "show desktop" icon.
3. the existence of alternatives: A user might not expect that A) alternatives exist B) it is possible from the widget itself to switch it and C) which alternative might contain the feature they are seeking
4. discoverability of features: a user coming from another desktop environment would not expect that widgets can be placed anywhere or that panels don't have to go over the full width of a screen.

5. uncommon UI paradigms: the way panel configuration is handled is completly different than anything else. A new user has to learn this new paradigm which is certainly not a pleasant experience when they just want to make a small change. As far as I can tell this is to a lesser extent true for "right-click to configure" as well since the idea to use the right mouse button seems to become extinct the more people are accustomed to smartphones.

Having all this information partly unobtainable without trials, partly hidden and additionally scattered makes the first attempts at configuration in the best case uncomfortable and in the worst case unsuccessful and frustrating. @ngraham has described an example of this in this task and another one in T10047: Guerilla UX testing: a GNOME switcher.

I am in favour of having a central location for configuring everything in addition to the per-widget configuration, like you have already discussed, but I am not convinced the system settings are the right place. It does solve the problem of scattering though.

I mainly want to suggest having a central application/window with further guidance concerning all the tasks the user might not expect to be separate which would help with (2,3,4). Such an application/window can contain the necessary information and help. The minimap or a similar solution would be part of this window to create a connection of its window contents and the configurable environment surrounding it (1) (I will present another approach further below). The configuration paradigms inside the window might solve (5).

I'll go ahead now and list tasks the user might want to perform there:
A. Panel: placement, size, configuration, add/remove
B. Widget: arrangement, size, configuration, add/remove
C. Wallpaper
D. look and feel of panels and widgets
E. Switching to the layout of another desktop environment

Aspects that I think the user would imo not expect at the same location as these: Settings concerning windows, fonts

The way I imagine how changing these aspects A-E could be done in an organized way is the following:
There are five sections/buttons, one for each aspect A-E. Those are color-coded and while the window has focus the corresponding elements of the UI would get matching colors: Panels get an orange box, separate widgets separate green boxes, wallpaper gets a yellow tint. Clicking one of the buttons A-E will guide the user to changing only that aspect of it. For example: Clicking A. "Panels" will lead to a panel configuration screen where panels can be added, removed, resized and moved around. Similarly for B. "Widgets". There could then be a button with a description next to it: "Click this button then click any of the widgets to configure it".

I will elaborate further if this is seen as a good direction but for now this is already too much text.

Yeah, this stuff is all second nature to us developers but to users--even potentially experienced users--it's not clear.

One more more data point here: I just handled a bug report from a user who has virtual desktops and upgraded from Plasma 5.15 to 5.16 using the Kubuntu backports PPA in Kubuntu 19.04. By all accounts, a fairly advanced user. This fellow could not figure out how to change a Task Manager setting. He managed to find the Panel configuration UI but didn't make it to the Task Manager's own settings page: https://bugs.kde.org/show_bug.cgi?id=408688

We discussed this at the Plasma + Usability & Productivity sprint. The following was our conclusion:

1. We create a new "global edit mode" (see T10190: (Re)define modes when editing panels and widgets and D22035: Port FolderView to ContainmentLayoutManager plugin).
2. In this mode: all windows fly into the corners via the Show Desktop effect to make the desktop visible as when showing the Widget Explorer; all panels become editable; a new horizontal toolbox appears at the bottom of each containment with buttons like Add Widgets and Change Wallpaper; all widgets cannot be interacted with directly (maybe they become de-saturated to show this); all widgets visibly show their widget-specific options (remove, configure, etc) and can be resized and rotated via anchors around their edges
3. We add a really obvious button in System Settings that says something like Configure Plasma (widgets, panels, & wallpaper) that will enter this mode when clicked.
4. We delete the Desktop Toolbox as it currently exists (see T10402: Find a way to remove the Desktop Toolbox in its current form (i.e. a hamburger menu button in the corner of the screen)) because all of its functionality has been moved into the new toolbox visible in the global edit mode. If necessary, we can create a new widget that only shows the name of the current Activity for people who miss this, or we add this functionality to the Activity Pager and make it show activities when there are more than one activities but only one virtual desktop (the way the Virtual Desktop Pager does when there's more then one virtual desktop)

In T11094#189845, @ngraham wrote:

We discussed this at the Plasma + Usability & Productivity sprint. The following was our conclusion:

1. We create a new "global edit mode" (see T10190: (Re)define modes when editing panels and widgets and D22035: Port FolderView to ContainmentLayoutManager plugin).
2. In this mode: all windows fly into the corners via the Show Desktop effect to make the desktop visible as when showing the Widget Explorer; all panels become editable; a new horizontal toolbox appears at the bottom of each containment with buttons like Add widgets and Change Wallpaper; all widgets cannot be interacted with directly (maybe they become desaturated to show this); zll widgets visibly show their widget-specific options (remove, configure, rotate, resize, etc).
3. We add a really obvious button in System Settings that says something like Configure Plasma (widgets, panels, & wallpaper) that will enter this mode when clicked.
4. We delete the Desktop Toolbox as it currently exists (see T10402: Find a way to remove the Desktop Toolbox in its current form (i.e. a hamburger menu button in the corner of the screen)) because all of its functionality has been moved into the new toolbox visible in the global edit mode. If necessary, we can create a new widget that only shows the name of the current Activity for people who miss this, or we add this functionality to the Activity Pager and make it show activities when there are more than one activities but only one virtual desktop (the way the Virtual Desktop Pager does when there's more then one virtual desktop)

+1

This sounds good to me, although we'll need to handle some (literal) corner cases like having two panels at a right angle to each other without a sufficient gap to avoid the panel configurator UIs overlapping. And probably some similar space issue with "zll widgets visibly show their widget-specific options (remove, configure, rotate, resize, etc).".

BTW: The VDG has some old mockups of Edit mode somewhere.

Yeah for the case where widgets are very small or close together, the handle that shows the buttons will have to be offset a bit, and maybe connected with a line or something.

This does sound like it could be a good solution. I am not quite sure if I am picturing this correctly.

In T11094#189880, @hein wrote:

BTW: The VDG has some old mockups of Edit mode somewhere.

Some kind of mockup would be much appreciated.

M43?

I like @ngraham idea as well!

@GB_2 's mentioned M43 has some interesting ideas also...

M43 looks fantastic! IIRC @mart has started implemented something pretty similar already so maybe we can align things.