Bug 368902 - Top-left cot corner doesn't work reliably when window extends to top-left corner
Summary: Top-left cot corner doesn't work reliably when window extends to top-left corner
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.7.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-16 14:18 UTC by Jonas Thiem
Modified: 2016-10-29 15:04 UTC (History)
1 user (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 Jonas Thiem 2016-09-16 14:18:52 UTC
The top-left cot corner doesn't work reliably when window extends to top-left corner. The cursor rapidly changes shape to resize cursor, grab cursor and normal cursor and jumps 1-2 px if you move it up there, with an apparent fight of the resize handler of the window corner and the hot corner of plasma.

This means the hot corner action only works if you slam the cursor in there multiple times persistently, which makes it almost useless since it's not possible to use it reliably (and as a result it's super frustrating to use).

Reproducible: Sometimes

Steps to Reproduce:
1. Move a non-maximized window such that the upper left corner reaches the top-left corner of your desktop
2. Set an action to the top-left hot corner
3. Try to use it

Actual Results:  
Sometimes the hot corner action works immediately, sometimes with a slight delay, sometimes I need to slam the cursor multiple times into the corner

Expected Results:  
Hot corner always triggers as soon as cursor has reached the corner and is moved more towards corner. If anything like the window resize handle displaces the cursor for some reason, this must never interfere
Comment 1 Martin Flöser 2016-09-16 16:32:08 UTC
The cursor is pushed back and there is a cooldown delay before you can trigger it again. Please go to systemsettings -> desktop behavior -> Screen edges and adjust the settings to your personal preferences.
Comment 2 Jonas Thiem 2016-09-17 13:14:05 UTC
Reopening. It is *very often* pushed back even when it wasn't there for a long time. It simply doesn't work reliably. Are you sure that is intended??
Comment 3 Jonas Thiem 2016-09-17 13:19:02 UTC
Ok I tested some more, and I believe the problem is the default Activation Delay.

It is way too high, and as a result you need to push with a lot of effort or it will simply appear to be sporadically not working. If you compare it to GNOME 3 where this feature is much more central, a slight tip with the mouse is enough. However, in KDE you need to consciously make either a very heavy push (which you don't do if this gesture is part of your trained workflow where it becomes a sort of non-attentive thing) or get frustrated with your gesture not being recognized all the time.

Therefore, I highly recommend lowering the Activation Delay to 10ms.
Comment 4 Martin Flöser 2016-10-28 18:47:28 UTC
The idea is to prevent activation by accident and due to that we decided for a strong push into the corner. Any change in that area requires proper user testing with a large sample base on different hardware (mouse, trackball, touchpad).

The comparison to how it is in GNOME doesn't hold as the corner has a much higher relevance in GNOME. In Plasma it's an addition but not a primary way to interact with the system.

Anyway KWin passes complete control to the user through settings which mean that every user can adjust to personal preferences and personal hardware responsiveness.
Comment 5 Jonas Thiem 2016-10-28 20:48:48 UTC
What do you mean, activation by accident?

The entire point is to have something happen if the cursor touches the corner, not to have something happen if the cursor is slammed for a whole second with notable effort (who wants to do that regularly for a mouse gesture anyway? Hello Repetitive Strain Injury around the corner). This is what the UI suggests the feature does, so this is what the default behavior should be geared towards.

It is all about user expectations with the default values, and right now your default values are chosen in a way that makes the feature seem brittle, almost broken with a "detection" that works 5% of the time.

There is nothing wrong with making this configurable, and nothing wrong with allowing users to configure it to require significant effort to do the gesture to make it not happen that easily IF THEY LIKE THAT, but the current default values are simply super unexpected and IMHO a usability disaster.
Comment 6 Jonas Thiem 2016-10-28 20:55:03 UTC
Clarification: a usability disaster for the given feature, simply because it is not obvious this needs to be configured to work reliably so it strongly suggests to be simply broken and buggy until the user manages to figure this out - in my opinion a pretty unfortunate way to default configure a feature, and not really reasonable way to choose a default configuration for it.

If you're that worried that some users don't want anything to happen if they accidentally use that gesture because they don't like it, you should probably simply not enable it per default in the first place instead of having a default activation level that makes it semi-useless unless altered. At least then you'd have a clear matched expectation that nothing happens, and in case a user enables it without immediately noticing the need for detail configuration, a clear matched expectations that it works reliably if enabled with no further tweaking - and people can still configure the detailed thresholds to their preferences if for some reason they liked the old works-but-hard-and-effortful-to-trigger behavior that is the current default.
Comment 7 Martin Flöser 2016-10-29 12:36:11 UTC
I have seen users getting under real stress and panic when they activated the top left edge by accident. That's why I say any change in that area requires user testing.

What we also saw in the past is a strong difference depending on the input device. On X11 we don't know what kind of device triggered the mouse input. On Wayland we could change depending on input device and it's configuration. But also that will require some user testing
Comment 8 Jonas Thiem 2016-10-29 15:04:55 UTC
In that case I propose simply disabling it per default, and allow advanced users to activate it.

This way, you can make a default configuration that focuses on making it easy to use when enabled, and inexperienced users won't accidentally trigger it and panic in the default state since it's turned off.

I would rather need to turn it on manually rather than being tricked into thinking it is implemented poorly, and as a result being frustrated with the desktop.

(of course this might just be my opinion, so feel free to ignore. The KDE desktop in general has sometimes a few rough edges tho, so I would rather recommend a config that is simple and allows simple changes, rather than trying to cater both for the super user and panicing default user with the same defaults and getting an IMHO weirdly half-usable in-between result that might appear to be broke to the usern)