Compatibility problems with latest GTK+ applications

[Thomas Lübking]

On Mittwoch, 7. Mai 2014 12:08:19 CEST, Aleix Pol wrote:

> Personally, I don't think we want to even try to convince them against.
> They're introducing interaction within the decoration space so they are
> committed to the idea.

That's actually not the point.
The correct way would have been to say "we want to introduce a new feature that requires interaction between WM and clients and may fail on legacy setups" and therefore push a new _NET_SUPPORTED item like "_NET_CLIENT_SIDE_DECORATIONS" and specify the interaction. Right now gtk+ dialogs are plain broken through unilateral proprietary deviation from the standard. Period.

> I would suggest to fill the found problems as bugs in GTK and get them to
> fix them hopefully. Most of them seem to be bugs afterall

The major bug here is that MWM is completely underspecified - we get a double decoration (on uncomposited environments) because KWin and enlightenment interpret MWM_DECOR_BORDER differently than metacity or openbox (implying "MWM_DECOR_TITLE" since it probably seemed stupid that a window should be resizable, but not movable through the WM UI) so the very first thing that needs to happen before even remotely thinking about widespread usage of CSD is a sane and explicit protocol in place.
(Notice that e18 is covered by the forced compositing only, e16 and e17 w/o compositing plugin behave exactly as KWin)


There MUST be a specified protocol in place.
That CAN invoke a specification of the MWM hints under the terms of NETWM (right now this is an internal protocol between motif WM and clients that other WMs and clients interpret as they feel like - it doesn't help that it's a bit crufted and clients twist logics on a rather regular base)
The protocol MUST include drag delays (time and space)
The protocol MUST include titlebar mouse actions (where i wonder what happens if the client gets shaded but the CSD doesn't support that ...)
The protocol MUST include invocation of the WMs context menu.
The protocol MUST include border actions (ie. what region should trigger what resize action)
The protocol SHOULD include titlebar button & label layout.
The protocol SHOULD include a way around hardcoded internal shadows which ignore the window state - otherwise we'll receive bug reports about gtk+ dialog shadows being broken.
The inferior alternative is that the protocol MUST include client ./. decoration areas (there's a present _GKT property, that must be turned into a _NET property)


And defining this protocol would have been the job of those who want the feature, not ours.
Right now, gtk+ dialogs are just a wild hack - thus the random usage and layout of extra buttons in the titlebar (nobody can tell me than any HIG guy has ever had a look on that).


Sum up:
gtk/gnome desperately wants to introduce CSD? Fine. But first please specify it.



> I've been using
> Chromium with CSD and I don't experience most of the described issues.


With chromium you WILL face following of the mentioned issues:
--------------------
* A hung window can no longer be closed or moved. Technical explanation: there 
is a ping protocol to detect hung applications. KWin only sends ping requests 
when the window is being closed from the window manager (e.g. decoration close 
button or Alt+F4).
* double border if decorations on KWin side are enforced [4] (Alt+F3 -> More 
Actions -> No Border). Technical explanation: GTK+ doesn't detect the re-
parenting and doesn't hide it's own deco and shadow
* Wrong resize cursor is shown on edges [6]
* Windows don't have a maximize and minimize button although configured in the 
decoration settings
--------
Notice that this boils down to the even more problematic aspect that the client easily comes with different button layout than the decoration - eg. the chromium close button is on the wrong side on my setup.
-------------
* Incorrect drag delay: KWin uses either a drag delay on distance or on time 
for starting move or resize. GTK+ only has a drag delay on distance for moving 
and none for resizing. That's an important accessibility feature to have that 
globally configurable
* Windows can no longer be shaded
* Windows can no longer be put into window tabs
* Ignores the configured mouse actions, uses (hard coded?) actions. Defaulting 
to lower window on middle click while we use window tab drag on middle click
* no visual distinction between active and inactive application
* Mismatching application window menu [8]. Note our menu could be invoked 
through DBus. I consider this as a big problem as that's the only way to e.g. 
add windows to activities (which is also broken now) or to access the advanced 
window manager features GNOME doesn't know of.
---------------
Actually chromium has its complete custom menu on the tabbar, which is also used on the optional CSD


You will NOT face:
--------------------
* quick tiling broken, see [1]. It includes the shadow in calculation.
* black shadows around window if compositing gets disabled after the window 
got opened [2]. Technical explanation: GTK+ doesn't detect that compositing 
gets enabled/disabled. Other direction is broken, too.
* Broken window snapping: window snaps to shadow [7]
-----------
Those are because chromium doesn't apply internal hardcoded mismatching static shadows like gtk dialogs push them down your throat. Instead, the window goes unshadowed (unless eg. oxygen-gtk would help a bit)
--------
* double borders if window gets opened when compositing is disabled [3]. 
Technical explanation: GTK+ uses the Motif Window Manager Hints to tell how 
the decoration should look like. KWin is not the Motif Window Manager and does 
not fully support the hints. Fun fact our code has a comment that we follow 
Metacity to only support those hints which are not stupid.
--------------
This is because chromium sets an empty MWM hint, what scratches all border & titlebar and is interpreted equal by most WMs (at least those which interpret MWM at all)
------------
* Dialogs don't have a close button [5] (unless run without compositing)
------------
It's not a dialog window ;-)


----
Sum up:
chromium makes "better" use of the MWM hints (on gtk+ it depends on the state of compositing whether the WM or the client triggers resizes because of their MWM usage...) and - so far - has no integrated client side shadows.



Cheers,
Thomas