GNOME Bugzilla – Bug 729792
No time based drag delay on window moving
Last modified: 2018-04-14 23:57:40 UTC
In a Plasma session window moving gets started by one or two globally configured options: * time based drag delay (default 500 msec) * distance based drag delay (default 4 pixel) GTK applications with client side decorations do not support the time based drag delay and by that removing important accessibility features as once the window move mode is entered the window can be moved using cursor keys. Steps to reproduce: 1. Start KWin 2. Start gtk3-demo (3.12.1) 3. click on the decoration and hold Actual result: Nothing Expected result: Window enters move mode
I must say that clicking and holding to initiate a keyboard based action sounds pretty awkward as an accessibility feature. In GNOME, you can start keyboard-controlled window moves using Alt-F7, and that works fine with csd windows.
whether it's awkward shouldn't matter. It's a regression in our desktop :-(
you're sidetracking the issue. of course kwin ha a shortcut to initiate moves/resizes, but the core issue here is that gtk apparently initiates the move immediately, ie. there's no dead time/space what would esp. impact maximized windows on clicks intended for activation only. the a11y issue here is that different ppl. require different time and judder to perform a click.
You get a cursor change when you are over the resize area. So you get feedback and can take as much time as you need to get your click in. I may just not get your point, sorry. Not sure how maximized windows are relevant here at all.They don't have any decoration you could click and drag on - except for the titlebar, where we _do_ have a time and distance based delay...
"Aero snap" stuff, accidental moving would too easily drop out of that state. But actually I forgot that I hardened that constellation anyway (iirc chromium triggered that...) - so this point is void for at least KWin (it glues the window and requires actual window movement to unmaximize) I checked and at least my gtk+ version indeed has a small dead drag area (though of course it doesn't follow KDE settings, not expectable) Basically i got Martin wrong on this. It's actually only about the fact that kwin enters the move mode by distance or delay independently (and gtk+ CSD indeed does not) Unfortunately i'm at hand not aware of the a11y concept behind this (ie. the benefit over the shortcut)
Well it's a useful protection for people having problems to properly control the mouse. By using a large drag distance they can be protected against accidental movements, while they still can easily enter the move mode by press and hold. As it is I know people needing such features. Anyway that gets side tracked. The point is the inconsistent behavior between what we expect windows to do in our environment and what GTK windows do.
I'm trying to figure out what the issue is. Does you receive a _NET_WM_MOVERESIZE that you handle immediately, instead of waiting for a delay?
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new