After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729792 - No time based drag delay on window moving
No time based drag delay on window moving
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: CSD
 
 
Reported: 2014-05-08 07:22 UTC by Martin Gräßlin
Modified: 2018-04-14 23:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Gräßlin 2014-05-08 07:22:42 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
Comment 1 Matthias Clasen 2014-05-11 14:19:20 UTC
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.
Comment 2 Martin Gräßlin 2014-05-11 14:42:38 UTC
whether it's awkward shouldn't matter. It's a regression in our desktop :-(
Comment 3 thomas.luebking 2014-05-13 17:17:20 UTC
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.
Comment 4 Matthias Clasen 2014-05-14 19:39:35 UTC
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...
Comment 5 thomas.luebking 2014-05-14 20:10:50 UTC
"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)
Comment 6 Martin Gräßlin 2014-05-15 05:40:22 UTC
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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2014-06-25 14:14:00 UTC
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?
Comment 8 Matthias Clasen 2018-02-10 05:12:14 UTC
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.
Comment 9 Matthias Clasen 2018-04-14 23:57:40 UTC
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