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 729793 - No drag delay on window resize
No drag delay on window resize
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:26 UTC by Martin Gräßlin
Modified: 2018-04-15 00:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Gräßlin 2014-05-08 07:26:30 UTC
In a Plasma session the windows only enter resize mode after a drag delay being either distance or time based. GTK+ applications using client side decorations do not honor this and enter the resize mode as soon as the window border is clicked.

Steps to reproduce:
1. Run KWin
2. Run gtk3-demo (3.12.1)
3. move pointer to border till resize cursor is shown
4. click and hold

Actual result:
Window enters resize mode

Expected result:
Window enters resize mode after either distance or time based drag delay passed.

This result in annoying flicker if one clicks the border as KWin makes the window translucent on window resize.
Comment 1 Jasper St. Pierre (not reading bugmail) 2014-06-25 14:14:36 UTC
You should apply this delay on the WM side by adding a delay when you get _NET_WM_MOVERESIZE events.
Comment 2 Martin Gräßlin 2014-06-25 14:25:24 UTC
(In reply to comment #1)
> You should apply this delay on the WM side by adding a delay when you get
> _NET_WM_MOVERESIZE events.

then we would have it twice for e.g. Oxygen which perfectly adds the same drag delay as KWin. Also should we just add the drag delay for time or distance (double with GTK) or use a whitelist to check which client includes which delay when sending the _NET_WM_MOVERESIZE event?
Comment 3 Jasper St. Pierre (not reading bugmail) 2014-06-25 14:40:28 UTC
Ah, so your client-side code also adds the same delay. I wasn't aware of this feature, and this has really never been standardized. I'd recommend that in the future you always apply the delay WM-side, but for now I'd just check if the _GTK_FRAME_EXTENTS property is set on the window and only add the delay in that case -- that's what we use to detect if a window is a GTK+ client-side-decorated window right now.
Comment 4 Martin Gräßlin 2014-06-26 06:40:07 UTC
again: difficult. If it uses the Oxygen GTK style it adds the time delay for the content area, but the header bar wouldn't. One of the two sides would break... We cannot adjust Oxygen either as that is also used in 4.x sessions and KWin 4.x won't be adjusted for such changes any more.
Comment 5 Jasper St. Pierre (not reading bugmail) 2014-06-26 11:53:19 UTC
"The time delay for the content area"?
Comment 6 Martin Gräßlin 2014-06-26 12:08:00 UTC
(In reply to comment #5)
> "The time delay for the content area"?

Oxygen has a feature to start move/resizing the window whenever you click on an "empty" area. E.g. the empty area next to a menu.
Comment 7 Matthias Clasen 2018-02-10 04:58:02 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 8 Matthias Clasen 2018-04-15 00:06:02 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