Bug 377309 - When using double-click mode, systemsettings inappropriately uses the same behavior in icon view
Summary: When using double-click mode, systemsettings inappropriately uses the same be...
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: iconview (show other bugs)
Version: 5.9.2
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
: 397434 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-03-06 21:07 UTC by Nate Graham
Modified: 2020-10-27 22:50 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.21


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2017-03-06 21:07:01 UTC
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.
Comment 1 Nate Graham 2017-03-06 21:10:34 UTC
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.
Comment 2 Nate Graham 2017-08-19 04:41:25 UTC
Fixed in the latest systemsettings.
Comment 3 Nate Graham 2018-04-05 18:56:48 UTC
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.
Comment 4 David Edmundson 2018-04-05 22:25:23 UTC
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?
Comment 5 Nate Graham 2018-04-05 22:29:09 UTC
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.
Comment 6 David Edmundson 2018-04-05 23:27:08 UTC
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.
Comment 7 Nate Graham 2018-04-06 02:09:08 UTC
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?
Comment 8 Luigi Toscano 2018-04-26 16:36:00 UTC
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.
Comment 9 Kai Uwe Broulik 2018-04-26 18:06:37 UTC
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.
Comment 10 argonel 2018-04-26 18:40:07 UTC
+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
Comment 11 Nate Graham 2018-12-17 16:02:35 UTC
*** Bug 397434 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2018-12-17 17:14:37 UTC
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.
Comment 13 David Edmundson 2018-12-17 17:46:29 UTC
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.
Comment 14 Nate Graham 2018-12-17 18:12:02 UTC
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.
Comment 15 David Edmundson 2018-12-17 22:38:59 UTC
>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.
Comment 16 Nate Graham 2018-12-17 23:09:08 UTC
(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.
Comment 17 Nate Graham 2018-12-18 03:50:00 UTC
I'm sorry. That last comment was really aggressive and rude. I didn't mean to offend!
Comment 18 Björn Feber 2019-10-04 17:23:07 UTC
This code in IconMode.cpp, line 183 fixes it:
d->categoryView->setStyleSheet(QStringLiteral("QAbstractItemView { activate-on-singleclick: 1; }"));
Comment 19 Nate Graham 2019-10-04 18:21:48 UTC
"Wanna submit a patch?" :)
Comment 20 David Edmundson 2019-10-05 14:07:07 UTC
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.
Comment 21 Bug Janitor Service 2020-10-21 21:30:54 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/systemsettings/-/merge_requests/35
Comment 22 Nate Graham 2020-10-27 22:50:23 UTC
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