GNOME Bugzilla – Bug 729772
CSD styled windows do not detect when re-parented to a decoration
Last modified: 2018-05-02 16:05:43 UTC
Created attachment 276122 [details] Reparented to a WM provided decoration A window manager might reparent the GTK+ window to a WM provided decoration. Not all window managers support the Motif hints or just ignore them. Steps to reproduce: 1. Run KWin 2. Start gtk3-demo (3.12.1) 3. Alt+F3 -> More Actions -> [ ] No Border Actual Result: KWin adds decoration, then there is the shadow, then the CSD border (see attached screenshot) Expected Result: GTK removes the custom decoration as WM sets a decoration. At least shadow should be removed. Note: this is an issue really important for reparenting tiling window managers not supporting Motif hints.
I am with you, except for the non supporting motif hints part. Window managers don't get off the hook so easily. And that users can produce broken configurations when you expose all the theme internals to them should be no surprise. Just don't do that.
we don't expose any theme internals to our users. So I don't understand what you mean by "just don't do that".
I mean 3. Alt+F3 -> More Actions -> [ ] No Border
well that's a feature we provide to our users. We always allow our users to fix windows. That's just one of several ways to get there. One can also set window rules or use scripting to influence the window border behavior. That's a really important design philosophy in KWin that the user always has the ultimate power over window management. Thus it's not an internal theme detail.
wanna see a magic trick? motif hints are nowhere specified. puff - WMs are off the hook. pretty impressive, eh? now, seriously: the motif hints have been an internal protocol of the motif toolkit and mwm. some other WMs support a random subset of them on random interpretation - they're free to do so because there's no specified meaning. several WMs ignore them completely. there's been discussion for over a year or so to remove support for those twisted mind legacy hints from kwin - completely regardless of any csd moves, but just because they're no required standard and the reverse flag causes clients to misuse them ever once again. iff you want to crucially rely on them (despite their wonky nature) the very first step would have been to add specification by asking for a netwm update that incorporates mwm hints by adding them to the supported list and esp. precisely define what behavior can be expected from what flag and how to resolve their crossings with netwm properties (buttons ./. window abilities)
(In reply to comment #4) > well that's a feature we provide to our users. We always allow our users to fix > windows. That's just one of several ways to get there. One can also set window > rules or use scripting to influence the window border behavior. That's a really > important design philosophy in KWin that the user always has the ultimate power > over window management. Thus it's not an internal theme detail. CSD applications blend the "border" and the application itself, as you can see in this nautilus screenshot: http://build.gnome.org/continuous/buildmaster/builds/2014/03/10/5/applicationstest/work-gnome-continuous-x86_64-runtime/screenshot-nautilus.desktop.png There is no border to remove anymore.
(In reply to comment #5) > wanna see a magic trick? > > motif hints are nowhere specified. They're specified by the Programmer's Guide as well along with the source dump. http://www.opengroup.org/openmotif/docs/m213.pdf http://www.opengroup.org/infosrv/openmotif/R2.1.30/motif/lib/Xm/MwmUtil.h Yes, they're bad and weird, but they're what we have. Suggestions for better ways of communicating this are welcome.
> http://www.opengroup.org/openmotif/docs/m213.pdf Non of the terms * mwminfo * _MOTIF_WM_HINTS * MWM_DECOR_BORDER appears in that document. Could you be so kind to mention the secion that specifies the WM behavior for MWM_DECOR_BORDER? > http://www.opengroup.org/infosrv/openmotif/R2.1.30/motif/lib/Xm/MwmUtil.h That header declares structure and values, but nowhere nearly specifies sth. like a meaning of the values. > Suggestions for better ways of communicating this are welcome. Communicating what? What you demand will by plain MWM behavior (i assume you tested MWM?) draw a border around the window, but will not allow it to be moved or resized by that border. From the composited behavior, i assume this is not what you actually want or need (the dialog is resizable in that case, feature provided by the client) I did frankly not understand in the first place why you didn't just unset MWM_HINTS_DECORATIONS, but require the WM to resize the window in the uncomposited case while you implement the resize handles in the client side... well, decorations(!) in the composited case. However. If you need a hint to have the window undecorated by the WM, the alternatives are to * incorporate a specification of MWM under NETWM terms or (because of the weird nature of the MWM hints) * revisit https://mail.gnome.org/archives/wm-spec-list/2014-February/msg00000.html If you actually need a hint to have the window decorated but untitled by the WM (so much for blending with client...), the alternatives are to * incorporate a specification of MWM (MWM_DECOR_BORDER to be interpreted as by metacity/compiz/mutter, ie. different than kwin/enlightenment/xfce) under NETWM terms or (because of the weird nature of the MWM hints) * revisit https://mail.gnome.org/archives/wm-spec-list/2014-February/msg00000.html with a more specific state/hint.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/488.