GNOME Bugzilla – Bug 729782
Window "disappears" when middle clicking client side decoration
Last modified: 2015-03-08 00:15:05 UTC
Steps to reproduce: 1. Run a Plasma session 2. Having several open windows 3. Open gtk3-demo 4. middle click the decoration Actual result: The window hides itself Expected result: nothing happens like with any other window on the desktop Note: KWin does not use lower as middle click action. In general GTK ignores all the actions being configured in KWin. Changing the actions doesn't have any effect on GTK windows.
How would gtk+ know anything about 'the actions being configured in kwin' ?
(In reply to comment #1) > How would gtk+ know anything about 'the actions being configured in kwin' ? for a started "not using CSD" would do ;-) Of course you could read our configuration file if the window manager is KWin or specify a new NETWM hint which the window manager sets to configure the action for the various mouse buttons. Note: in KWin we allow to customize the actions independently for left, right, middle, left double click, wheel and mouse clicks can differ for active and inactive windows. We consider it as important that our users are able to configure these actions.
This also happens in GNOME when one uses gnome-tweak-tool and selects "maximize vertically" as the action (or, really, any other action) — Unexpectedly, CSD windows disappear behind others.
What can we do on the GTK+ to help you out?
(In reply to comment #4) > What can we do on the GTK+ to help you out? I think this needs standardization that instead of performing a random action a client message is sent to the window manager. The window manager can then easily trigger its own configured action.
I am OK with this approach. How about a _NET_WM_PERFORM_BUTTON_ACTION ClientMessage with a device_id, button, and timestamp? Do you need anything else? If you're OK I will write this code for GTK+ and mutter.
*** Bug 705825 has been marked as a duplicate of this bug. ***
*** Bug 707167 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > I am OK with this approach. How about a _NET_WM_PERFORM_BUTTON_ACTION > ClientMessage with a device_id, button, and timestamp? Do you need anything > else? maybe root_x and root_y from the event. At least for context-menu action we need to know the position where to show the menu (that's also missing in the show window menu client message).
(In reply to comment #9) > maybe root_x and root_y from the event. At least for context-menu action we > need to know the position where to show the menu (that's also missing in the > show window menu client message). We actually added it back, for the keyboard case where you might want a keyboard shortcut to open the window menu. Unfortunately, we only have room for four parameters because yay ClientMessage. Can't you do XIQueryPointer on the passed device ID to get the X/Y of the respective cursor?
> Can't you do XIQueryPointer on the passed device ID to get the X/Y of the respective cursor? we don't use XInput yet :-) Bad argument, I know :-D I think it wouldn't help as we would need to look into the past to get the coordinate back at that timestamp. With a touch screen or touch pad I could imagine that at the time we get the client message the cursor already changed the position significantly. Maybe timestamp is not needed? What was the reason that you wanted to add it?
The timestamp is needed when you do any user action like raising or lowering to make sure the stack is ordered correctly. If your stack doesn't support multiple devices yet, you can just use XQueryPointer directly and ignore the passed in device_id. mutter uses XI2 internally for some of the new features in XI2, but doesn't actually support multiple devices properly -- we just ignore any pointers/keyboards other than the Virtual Core Pointer and Virtual Core Keyboard.
ah well, should work good enough.
> Unfortunately, we only have room for four parameters because yay ClientMessage. wait, we have 5, so we can include x and y. See http://tronche.com/gui/x/xlib/events/client-communication/client-message.html "The data member is a union that contains the members b, s, and l. The b, s, and l members represent data of 20 8-bit values, 10 16-bit values, and 5 32-bit values."
sent a proposal to netwm spec list: https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html
Created attachment 287037 [details] [review] Factor out titlebar click actions So they can be made configurable.
Created attachment 287038 [details] [review] Add settings for titlebar actions These match the GSettings that mutter/metacity/gnome-shell have for this.
Created attachment 287039 [details] [review] Implement titlebar action settings for X11
Created attachment 287040 [details] [review] Implement titlebar action settings for Wayland
Created attachment 287041 [details] [review] Use titlebar action settings for CSD windows Instead of hardcoding these actions, consult the settings. Note that not all of the actions supported by gnome-shell are implemented here, only maximize, minimize, lower, and menu.
since this seems to have gone nowhere, here's an alternative approach
I'm still interested in getting it into NETWM, I'm just lacking huge amounts of time to work on it :-(
Attachment 287037 [details] pushed as d20fdd1 - Factor out titlebar click actions Attachment 287038 [details] pushed as 1d8a1a0 - Add settings for titlebar actions Attachment 287039 [details] pushed as 69a44ee - Implement titlebar action settings for X11 Attachment 287040 [details] pushed as 6604f00 - Implement titlebar action settings for Wayland Attachment 287041 [details] pushed as fcec9b9 - Use titlebar action settings for CSD windows
pushed these for now so we have parity between traditional and CSD windows in GNOME. If a netwm titlebar action thing appears, we can use that where available, and fall back to this client-side handling.
nothing left to do here but wait for netwm