After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729772 - CSD styled windows do not detect when re-parented to a decoration
CSD styled windows do not detect when re-parented to a decoration
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: CSD
 
 
Reported: 2014-05-08 05:42 UTC by Martin Gräßlin
Modified: 2018-05-02 16:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Reparented to a WM provided decoration (62.62 KB, image/png)
2014-05-08 05:42 UTC, Martin Gräßlin
Details

Description Martin Gräßlin 2014-05-08 05:42:03 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.
Comment 1 Matthias Clasen 2014-05-11 13:51:54 UTC
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.
Comment 2 Martin Gräßlin 2014-05-11 14:27:32 UTC
we don't expose any theme internals to our users. So I don't understand what you mean by "just don't do that".
Comment 3 Matthias Clasen 2014-05-11 15:43:33 UTC
I mean

3. Alt+F3 -> More Actions -> [ ] No Border
Comment 4 Martin Gräßlin 2014-05-11 16:09:34 UTC
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.
Comment 5 thomas.luebking 2014-05-13 18:03:26 UTC
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)
Comment 6 Jasper St. Pierre (not reading bugmail) 2014-06-25 14:40:46 UTC
(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.
Comment 7 Jasper St. Pierre (not reading bugmail) 2014-06-25 14:52:52 UTC
(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.
Comment 8 thomas.luebking 2014-06-25 18:46:18 UTC
> 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.
Comment 9 GNOME Infrastructure Team 2018-05-02 16:05:43 UTC
-- 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.