Bug 201523 - [PATCH] Support _MOTIF_WM_HINTS decoration toggling
Summary: [PATCH] Support _MOTIF_WM_HINTS decoration toggling
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.2.2
Platform: Ubuntu Linux
: HI normal
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2009-07-26 09:05 UTC by Daniel Erat
Modified: 2010-06-20 03:00 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:

patch to show or hide border when Motif WM hints change (4.13 KB, patch)
2009-07-26 09:12 UTC, Daniel Erat
test program to illustrate the issue (2.27 KB, text/plain)
2009-07-26 09:14 UTC, Daniel Erat

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Erat 2009-07-26 09:05:00 UTC
Version:            (using KDE 4.2.2)
OS:                Linux
Installed from:    Ubuntu Packages

The Chrome web browser has a feature where it draws its own window decorations.  When this setting is toggled, Chrome calls gtk_window_set_decorated(), which makes GTK change the window's requested decorated state via the _MOTIF_WM_HINTS property.  kwin honors this property on new windows but doesn't always respect it when it changes, so already-open windows sometimes don't get updated when the setting is changed.  More specifically, if an already-open window requests no decorations, kwin removes the window's border, but if the window then requests decorations, the border doesn't get re-added.
Comment 1 Daniel Erat 2009-07-26 09:11:31 UTC
The patch that I'm about to attach (written against head but tested against 4.2.2) appears to fix this.  I'm also attaching a small test program that illustrates the issue -- compile decorations.c and run it with 1 or 0 as an argument to start with the border shown or hidden.  Middle-clicking on the window makes it toggle the decorations setting in the _MOTIF_WM_HINTS property to attempt to show or hide the border.
Comment 2 Daniel Erat 2009-07-26 09:12:56 UTC
Created attachment 35639 [details]
patch to show or hide border when Motif WM hints change
Comment 3 Daniel Erat 2009-07-26 09:14:14 UTC
Created attachment 35640 [details]
test program to illustrate the issue
Comment 4 lucas 2009-10-03 16:32:28 UTC
SVN commit 1030932 by lmurray:

Detect when _MOTIF_WM_HINTS gains or loses the no border hint.
Patch by Daniel Erat.
BUG: 201523

 M  +12 -5     client.cpp  
 M  +2 -1      client.h  
 M  +6 -5      utils.cpp  
 M  +8 -3      utils.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1030932
Comment 5 lucas 2009-10-03 16:39:30 UTC
SVN commit 1030933 by lmurray:

Backport r1030932:
Detect when _MOTIF_WM_HINTS gains or loses the no border hint.
Patch by Daniel Erat.
CCBUG: 201523

 M  +12 -5     client.cpp  
 M  +2 -1      client.h  
 M  +6 -5      utils.cpp  
 M  +8 -3      utils.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1030933
Comment 6 johnjaylward 2009-12-04 22:27:14 UTC
This bug still seems to be a problem in KDE 4.3.4 running on QT 4.6.0. I have the problem with both Chromium and with the test file attached here.
Comment 7 Aldoo 2010-02-11 15:19:52 UTC
Still a problem in 4.4.0.

Has the patch really been applied?
Comment 8 lucas 2010-02-12 01:17:32 UTC
Yes, the patch has been applied. If it's not working then either the patch is incorrect or there is a another bug somewhere.
Comment 9 David Benjamin 2010-06-20 02:57:58 UTC
comment #6: The test case doesn't pass because it is wrong; the int array should be made of longs to account for XChangeProperty doing some word size twiddling. I presume you are running a 64-bit machine? The corrected test case should already pass on kwin.

The change in Chrome still doesn't work because of two issues relating to XShape, which the client-side-decorations version of Chrome uses. I've made three patches. The first two fix it, and I'd like to commit them in time for 4.4.5, pending review. (The third is related and I'd like to land it in trunk.)

Comment 10 David Benjamin 2010-06-20 03:00:10 UTC
> which the client-side-decorations version of Chrome uses

Er, that was somewhat ambiguous. I mean that Chrome uses XShape when it is configured to draw its client-side decoration. Kwin doesn't react properly to it ceasing to set a custom shape when you turn the system title bar on.