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
