Compatibility problems with latest GTK+ applications

[Aleix Pol]

On Wed, May 7, 2014 at 10:11 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:

> Hi all,
>
> I need some advice. The new GTK+ release introduced and enforces
> client-side-
> decorations (CSD) and that is causing severe compatibility problems with
> Plasma Workspaces (especially the stable release which we cannot adjust any
> more). I'll give a list of issues below.
>
> I'm not sure what we can do about it. I think we need to do something about
> it, because this looks like a road back to "GTK apps can only be used in
> GNOME
> Shell" resulting in "KDE apps can only be used in Plasma". Because of that
> I
> think the compatibility problems matters to everyone also our application
> developers. I think the right thing is to contact the GTK+ developers and
> point out the problems, but I am probably the wrong person for it as I'm a
> known opponent of CSD and fear that my feedback would be ignored. As a
> fallback strategy we could enforce server-side-decorations (SSD) for all
> GTK+
> applications which would look strange [4] but at least no loss in
> functionality.
>
> Of course there are things we can do in KWin to improve compatibility, but
> 4.11 is feature frozen and these would require new code and we have
> certainly
> more important things to do than to fix client breakage (we don't do that
> in
> general).
>
> It would be way easier if GTK+ would detect whether the environment
> supports
> CSD and use a normal application design if that's not supported. This would
> not only be relevant for us, but especially for tiling window managers.
>
> List of issues I noticed:
> * 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).
> * 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.
> * 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.
> * 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
> * 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
> * Dialogs don't have a close button [5] (unless run without compositing)
> * 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
> * Broken window snapping: window snaps to shadow [7]
> * 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.
>
> That list I figured out in less than 10 min usage of a new GTK+
> application. I
> assume and fear that the list is much longer.
>
> Any advice on how to handle this situation is appreciated.
>
> Cheers
> Martin
>
> [1]
>
> https://picasaweb.google.com/lh/photo/_q8BS4WN91ZvjEGSsiUkqtMTjNZETYmyPJy0liipFm0?feat=directlink
> [2]
>
> https://picasaweb.google.com/lh/photo/hGjW0RLjGF3UVw5wFnPMqdMTjNZETYmyPJy0liipFm0?feat=directlink
> [3]
>
> https://picasaweb.google.com/lh/photo/hriAb8OI1Yh8BtxtAg5bG9MTjNZETYmyPJy0liipFm0?feat=directlink
> [4]
> https://picasaweb.google.com/lh/photo/9LLTICdSJhcHl-SCBWc_i9MTjNZETYmyPJy0liipFm0?feat=directlink
> [5]
> https://picasaweb.google.com/lh/photo/-krx0xvGFjq9TwkEC4Bh_tMTjNZETYmyPJy0liipFm0?feat=directlink
> [6]
> https://picasaweb.google.com/lh/photo/BfuvOcm0_v_BG-SkoxXJ29MTjNZETYmyPJy0liipFm0?feat=directlink
> [7]
>
> https://picasaweb.google.com/lh/photo/Vya50RqaVq1ij6sMDHEnbdMTjNZETYmyPJy0liipFm0?feat=directlink
> [8]
> https://picasaweb.google.com/lh/photo/2Xa5xNqDmjGL-bXwFzmPWdMTjNZETYmyPJy0liipFm0?feat=directlink


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.

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, I've been using
Chromium with CSD and I don't experience most of the described issues.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140507/37f05c97/attachment.htm>
-------------- next part --------------
_______________________________________________
Plasma-devel mailing list
Plasma-devel at kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel