Plasma 5.9.2 on OpenSUSE Tumbleweed SUMMARY systemsettings icons always respond to a single-click irrespective of Dolphin's files and folders click behavior STEPS TO REPRODUCE: 1. systemsettings > Input Devices > Mouse > "Double-click to open files and folders ()select icons on first click)" 2. Close and re-open systemsettings 3. Make sure systemsettings is using icon view, not tree view 4. Single-click on any of the icons EXPECTED RESULT: Clicking on the icon should take you to a new page, since it's a button, not a file or a folder ACTUAL RESULT: Clicking on the icon uselessly selects it, and you have to double-click to go to the desired new page. These icons are buttons, not files or folders. Buttons produce their desired action on a single-click; a double-click behavior doesn't make any sense here.
Related: https://bugs.kde.org/show_bug.cgi?id=254431 However in my case this occurred on a brand new install (just set up the system yesterday and this was the first thing I changed). If this is caused by an OpenSUSE patch, let me know and I'll take it up with them.
Fixed in the latest systemsettings.
Well, not really fixed, just worked around by changing the default to be a list instead of icons view. The problem remains for people who prefer the icons view and use double-click as their preferred click mode.
I dont' understand the problem. If you set double click mode you should get double click mode. Also you've closed and reopend it yourself. What's the status?
Current status: still an issue; was previously closed for the wrong reason back when I was a bugzilla n00b. The bug is that the icons in System Settings Icon view should ignore the setting and always activate on a single-click the way buttons do, since in icons view they're behaving as buttons. There's no reason to make people double-click them, since there are no actions that can be performed on them when selected.
It's not just system settings, it's all icon views; and it's been that behaviour since forever. The code explicitly goes out of it's way to set it (it's our QPT: QPlatformTheme::ItemViewActivateItemOnSingleClick) before that it was handled in our KItemViews subclasses. > There's no reason to make people double-click them, There's no reason to double click anything. But a user has explicitly opted in for it. It's not for us to say that the double click is pointless. Text in the KCM could change, behaviour can't.
I feel like I may not be expressing myself very clearly here. Let me try again: It only makes sense for something to be double-clickable if there are things you can do with it when it's selected, but not yet open. Changing the setting to double-click affects the behavior for clicking *files and folders.* The purpose of using double-click when applied to files and folders is to make selection easier, because files and folders have a lot of things you can do with them once they're selected. Changing the setting to double-click does *not* change the number of clicks required to activate buttons or menus. This is because these UI elements never need to be selected, and there is nothing you could do with them after selection even if you could select them. I am asserting that the icons in System Settings Icon mode have more in common with buttons than they do with files and folders because they never need to be selected, as evidenced by the fact that when double-click is set, they erroneously *can* be selected, but there's nothing special you can do with them. Ergo, it makes sense to treat them like buttons rather than files, and always activate them with the first click regardless of whether single-click or double-click is the click method for files and folders. Does that make sense?
As a double-click user with a systemsettings configured in icon mode, I disagree with this request. I want consistent double-click for those icons too.
There's nothing to select in system settings so it doesn't make sense to have double click there. I have observed newcomers to Plasma, even former Windows users (which uses double click almost everywhere), to struggle with this, actually.
+1 For those that prefer double-click mode, my assumption is that there's no desire to focus a KCM's icon and *do* something with it, but rather to avoid the unwanted effects that arise from having double-clicked on an icon that actually responded to a single click. Some additional considerations, perhaps especially when double-click mode is on: 1) reject click-through (with an eye to accessibility) 2) reduce the clickable area of a icon so that there's ample whitespace for a click to focus the window without activating a KCM 3) swallow the second click of a double-click so as to avoid activating something in the KCM that the first click activated 4) ensure that keyboard navigation works correctly so that one doesn't have to click in the icons view in order to reach the desired KCM icon
*** Bug 397434 has been marked as a duplicate of this bug. ***
Let me be very clear regarding why this is a valid issue: 1. A thing that is not mouse-selectable (e.g. a toolbar button) should always activate with a single click even when using the double-click setting 2. The double-click exists because some people prefer for the first click on a mouse-selectable item to select it rather than open it, so they can more easily perform actions on the selected item(s) 3. A thing should only be mouse-selectable when there are actions besides (open/execute) that can be performed on it when selected Because the icons in System Settings icons view have no actions besides open/execute that can be performed on them when selected, they should not be mouse-selectable, which means they should always activate on single-click. They can still be keyboard-focusable for the purpose of keyboard navigation, but that's an entirely different matter, since *everything* should be keyboard-focusable.
And I'll reiterate why it should't change. If it looks like an icon it should behave like an icon. Anything else means unpredictable behaviour for the user. A user approaching it doesn't know whether there's additional actions or not when they're first mouse clicking.
David, you didn't address any of my arguments. I will be happy to address the new ones you introduced, and I hope you will take the time to do the same for mine. > If it looks like an icon it should behave like an icon. Icons do not have a set, predictable behavior. An icon is a visual symbol that is added to an interactive user interface element that supplies the behavior. For example, icons can be found on pushbuttons, menu items, list items, status indicators, and files or folders in a file manager. How these elements respond to clicks depends on the UI element itself, not the presence, absence, or appearance of an icon. Notably, Gwenview's thumbnail view respects the single/double click settings without having any icons whatsoever (it has thumbnails instead). The single/double click setting has nothing to do with whether the element looks like a file or folder in Dolphin. > A user approaching it doesn't know whether there's additional actions or not when they're first mouse clicking. This is precisely why the traditional appearance of pushbuttons is actually buttonlike. The modern trend of making pushbuttons borderless is what generates this confusion. A button with an icon in it that actually looks like a button produces no confusion regarding what it is or how you're supposed to click it. Regardless, there's a simple solution to this issue that does not require changing the visual appearance of anything that's single-clickable: make the mouse cursor use a finger cursor when hovered over it. That's the entire point of the finger cursor: it says, "this will open something new or take you somewhere else when you click". It's a visual cue that was invented precisely to alleviate the potential confusion regarding how many times you need to click on something.
>you didn't address any of my arguments. >1. A thing that is not mouse-selectable (e.g. a toolbar button) should always activate with a single click even when using the double-click setting Whether it's mouse selectable (and FWIW it is mouse selectable) or not isn't relevant, what's relevant is expected action. Like how we write "..." at the end of menus and buttons that will spawn dialogs. Users learn patterns. If something looks like something familiar, it should always behave like that familiar thing. Standalone icons in a grid in a frame should behave like standalone icons in a grid in a frame. There's no indication as to whether there's additional actions. You need that visual clue. And yes you could do it with a hover hand mouse over, but that's coming up with a solution for something that has yet to be shown is a problem. > 2. The double-click exists because some people prefer for the first click on a mouse-selectable item to select it rather than open it. That's guessing, the only thing we know is a user has gone explicitly out of their way to turn this on. Copying the response in #10, it could be for: 1) reject click-through (with an eye to accessibility) 2) reduce the clickable area of a icon so that there's ample whitespace for a click to focus the window without activating a KCM 3) swallow the second click of a double-click so as to avoid activating something in the KCM that the first click activated 4) ensure that keyboard navigation works correctly so that one doesn't have to click in the icons view in order to reach the desired KCM icon > 3. A thing should only be mouse-selectable when there are actions besides Basically covered in 1.
(In reply to David Edmundson from comment #15) > > 2. The double-click exists because some people prefer for the first click on a > > mouse-selectable item to select it rather than open it. > > That's guessing, the only thing we know is a user has gone explicitly out of > their way to turn this on. It is not guessing, it's literally the only reason to use double-click. If you don't understand why someone would prefer double-click, then you have no frame of reference for understanding the basis of this request. Also, Kubuntu has double-click as the default setting now, so all of the Kubuntu users have to go out of their way to use single-click. (In reply to David Edmundson from comment #15) > Users learn patterns. If something looks like something familiar, it should > always behave like that familiar thing. Standalone icons in a grid in a > frame should behave like standalone icons in a grid in a frame. Let's get conceptual: If two things behave the same, they should look the same. Kinda-sorta-similar (e.g. "icons in a grid in a frame") doesn't cut it. Identical or bust. This is one of the major user-centric reasons why widget toolkits exist: so that things that behave identically actually look identical. That's the only way users learn patterns. In a nutshell: - Identical appearance == "I know how this works!" - Even slightly different appearance == "I wonder what this weird new thing does? It's kind of similar to this other thing, but does it work the same? If it did, wouldn't it look the same? I don't know..." Dolphin's Icons view does not look identical to System Settings' Icon view. The icons are similar but not quite identical (e.g. Dolphin icons do not have a full-size highlight), and everything else is different: the background color, the presence of those group separator thingies, and the whole context: everyone knows what a file manager is and what a settings app is and the differences between them. Nobody looks at System Settings' icon view and thinks, "I bet these things behave just like to my file manager." That argument breaks down anyway because Dolphin has list and tree views that also respect the single/double-click setting, but it would be ridiculous to apply the setting to list items in other contexts.
I'm sorry. That last comment was really aggressive and rude. I didn't mean to offend!
This code in IconMode.cpp, line 183 fixes it: d->categoryView->setStyleSheet(QStringLiteral("QAbstractItemView { activate-on-singleclick: 1; }"));
"Wanna submit a patch?" :)
I will still be against it on account of if you've set your settings to make a grid view activate on double click, then having a grid view activate on double click is not a bug. Also if you were to patch it...don't do that. Just change the relvant handler from activated to clicked.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/systemsettings/-/merge_requests/35
Git commit 48b0e798a4513e85899e2af3560fb268fbee9ee9 by Nate Graham. Committed on 27/10/2020 at 22:47. Pushed by ngraham into branch 'master'. [Icon view] Always open KCMs on single-click Now that we're clarified that the double-click setting is only supposed to apply to file and folder views, we can make System Settings' icon grid always activate KCMs on single-click (which is what people seem to expect even when using the systemwide double-click setting) because it's not a file or folder view. FIXED-IN: 5.21 M +2 -0 icons/IconMode.cpp https://invent.kde.org/plasma/systemsettings/commit/48b0e798a4513e85899e2af3560fb268fbee9ee9