Bug 466050 - Triggering selection mode by accident
Summary: Triggering selection mode by accident
Status: RESOLVED DUPLICATE of bug 465489
Alias: None
Product: dolphin
Classification: Applications
Component: Selection Mode (show other bugs)
Version: 22.12.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KFM Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-19 04:15 UTC by Riku
Modified: 2023-02-23 16:12 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Riku 2023-02-19 04:15:55 UTC
SUMMARY
While I'm sure this feature is great for touchscreen users, as a heavy keyboard user I find myself triggering selection mode exclusively by accident. The thing is, why would I ever want to use selection mode if I'm not limited to touch controls? On a keyboard it's more or less worthless and even with a mouse, ctrl/shift + left click and right click for actions works fine.

Some possible solutions come to mind.
A. Add an option to fully disable selection mode.
B. Do not trigger selection mode with keyboard. It could still be triggered with mouse or touch.
C. Put selection mode on some shortcut that won't be constantly hit by accident.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.27.0
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Comment 1 Felix Ernst 2023-02-19 12:15:22 UTC
>On a keyboard it's more or less worthless

The Ctrl+Arrow keys and Ctrl+Space keyboard shortcuts aren't that discoverable so having another more guided approach for multi-select helps the average user. Also see https://bugs.kde.org/show_bug.cgi?id=458091, which is about making selection mode more useful for keyboard users.

>with a mouse, ctrl/shift + left click and right click for actions works fine.

Absolutely, but again: Ctrl/Shift+click isn't that discoverable. Many users don't know about it, or aren't even used to using the keyboard and mouse together for "shortcuts". I noticed that without selection mode, some users weren't able to select multiple files unless they fit into a "selection rectangle" i.e. the thing that shows up when one draws a rectangle in the view area.

Similarly, we have a rule in KDE not to expect users to be aware of right-click functionality because it is a somewhat hidden way to interact with the system by design.

>triggering selection mode exclusively by accident

Which keyboard shortcut are you triggering by accident? Mostly the Space key shortcut or others as well?
Comment 2 Riku 2023-02-19 13:32:10 UTC
File manager GUIs have worked more or less the same for as long as I can remember and now suddenly the muscle memory is destroyed. But I won't argue against accessibility and it's great that people are actually thinking about this stuff. It's just that it seems to always come at the expense of irritating proficient users.

>Which keyboard shortcut are you triggering by accident? Mostly the Space key shortcut or others as well?
Mostly space indeed. I noticed there was already some discussion about allowing rebinding space which would help a lot! However I do also end up hitting copy or cut on an empty selection.
Say I try to copy but the file I thought was selected isn't. Now I would instinctively try space, which actually exits selection mode. Even with the original behavior of space restored, entering selection mode on an empty copy is not what I wanted and doesn't help me in terms number of key presses, etc.
I just don't see myself ever benefitting from selection mode, only having to cancel it after having mistakenly activated it.

I'd like to hear your thoughts on my proposed solutions.
Comment 3 Dashon 2023-02-19 23:37:14 UTC
Hey, just wanted to chime in on this. Previously I was able to unbind space from select files and folders in the keyboard shortcuts. I changed it to Control + ' when it was mentioned that we could do that in this bug report https://bugs.kde.org/show_bug.cgi?id=458282. Now changing the shortcut does work, but it seems that as of 22.12.2. Spacebar once again enters selection mode regardless of what is set in the keyboard shortcuts? It's like all I have done is added an additional keybinding to it. Is this happening for anyone else?
Comment 4 Riku 2023-02-20 10:56:08 UTC
Dashon, regarding space specifically there's a related report here https://bugs.kde.org/show_bug.cgi?id=465489
Comment 5 Dashon 2023-02-20 13:38:38 UTC
(In reply to Riku from comment #4)
> Dashon, regarding space specifically there's a related report here
> https://bugs.kde.org/show_bug.cgi?id=465489

Thanks, that certainly sheds light on the situation.
Comment 6 Felix Ernst 2023-02-23 13:30:23 UTC
(In reply to Riku from comment #2)
> File manager GUIs have worked more or less the same for as long as I can
> remember and now suddenly the muscle memory is destroyed. But I won't argue
> against accessibility and it's great that people are actually thinking about
> this stuff. It's just that it seems to always come at the expense of
> irritating proficient users.

Yea, I think there is often times not much way around that. After all, the most proficient computer users use keyboard shortcuts (often) and are therefore more likely to gain muscle memory for pretty much any action. If we want to change anything for the benefit of average users it is somewhat unavoidable in many situations that it causes disruption/irritation for proficient users. The most bug reports we got for a change in the last year was about the pre-selected button on the permanently delete dialog switching from "Delete" to "Cancel". It broke muscle memory and even though it is not completely stupid to have "Cancel" pre-selected, many users were getting really angry over it until I fixed it. See https://bugs.kde.org/show_bug.cgi?id=462845.

> >Which keyboard shortcut are you triggering by accident? Mostly the Space key shortcut or others as well?
> Mostly space indeed. I noticed there was already some discussion about
> allowing rebinding space which would help a lot! However I do also end up
> hitting copy or cut on an empty selection.
> Say I try to copy but the file I thought was selected isn't. Now I would
> instinctively try space, which actually exits selection mode. Even with the
> original behavior of space restored, entering selection mode on an empty
> copy is not what I wanted and doesn't help me in terms number of key
> presses, etc.
> I just don't see myself ever benefitting from selection mode, only having to
> cancel it after having mistakenly activated it.
> 
> I'd like to hear your thoughts on my proposed solutions.

This is generally not a good use of my time. I'll answer briefly but please don't expect a back-and-forth discussion to come from this.

>A. Add an option to fully disable selection mode.

Seems like a somewhat weird way to solve this bug report to me. Selection mode isn't really meant to be a feature that users have to live with. It is supposed to only be triggered after explicit user action. It wouldn't really make a lot of sense to have an action in the UI and then a separate setting in the settings to disable that action.

>B. Do not trigger selection mode with keyboard. It could still be triggered with mouse or touch.

This does make some sense for the specific issue in mind, but it is also totally inconsistent with every other action in KDE applications. Having actions that act differently depending on how they are triggered goes against many expectations. So while I agree that it would make some sense in the given case, I consider it overall a harmful precedent that can be solved differently.

>C. Put selection mode on some shortcut that won't be constantly hit by accident.

From the feedback I have gathered (which has been overwhelmingly positive at times) it seems like a good idea to make selection mode easily accessible by default. There is no way to get representative statistics on this because we have no way to gather representative data of our user base (only opt-in which computer-illiterate people who are part of the target user group of this feature won't have enabled). 

So, changing the shortcut away from Space by default doesn't seem like a great idea to me currently. It is not totally out of the picture but AFAIK we don't have enough reason to assume that this is the issue.

Being able to change the key-binding of selection mode on the other hand does seems like a good idea, which is why my favourite solution for this bug report would be marking it as a duplicate of https://bugs.kde.org/show_bug.cgi?id=465489.

This, however, doesn't address the other issue you mentioned about activating selection mode by accident e.g. by pressing Ctrl+C when nothing is selected. I don't really think this is something we need to fix. Maybe I am weird, but I generally don't press keyboard shortcuts by accident unless they are very close to each other. That's an issue for example with Ctrl+Q (quit application) right next to Ctrl+W (close tab). However we aren't going to remove the Ctrl+Q shortcut by default because having that is normal among pretty much every application. In the same way we shouldn't remove keyboard shortcuts out of fear that users are going to press them accidently, especially when the only thing that happens then is that a bar is shown which can be closed again in many different ways.

There are also real advantages to having an action that would previously silently fail now guide the users towards success, but I don't want to also get into details on this detail as well.

Would it be fine with you if I marked this bug report as a duplicate of https://bugs.kde.org/show_bug.cgi?id=465489 ?
Comment 7 Riku 2023-02-23 15:21:03 UTC
Entering selection mode on actions like copy just seems redundant to be honest.

But admittedly, copying on an empty selection is not that regular of an occurrance and maybe I could learn to live with how it works once space is fixed. While this isn't ideal for me personally, I don't see a good solution right now. I (reluctantly) agree to mark as duplicate.
Comment 8 Felix Ernst 2023-02-23 16:12:12 UTC
Thank you for understanding!

*** This bug has been marked as a duplicate of bug 465489 ***