My assumption is (could be argb issue, though) that gtk3 sets MWM to hide the deco (does) and then for some reason (plugin to fix the headerbar rubbish?) withdraws that hint.
Fluxbox correctly adheres to the former but would presently and wrongly ignore the latter.
The patch fixes that.
Whether that's the case I can't say (waiting for reply on the bug)
As long as gtk does set the "proper" MWM hint (and not withdraw it), the window will remain undecorated. This would only be "fixable" by "ignore MWM because shitty gtk abuses it" (what i'd personally not endorse at all)
However, at least here gtk3 sets the MWM hint only for windows which it provides a headerbar (incl. CSD), ie. such which are supposed to not be decorated by the WM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the last time i started to examine the situation my conclusion was similar to yours: gtk3 "sets" / "removes" some props on the window and sometimes it's bad timing in the sense that fluxbox already provided the "functions" (to allow movement etc). the last time i checked i had a hard time to find some good documentation about how CSD is supposed to work at all.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's not specified at all what is a major complaint. The strategy is "we make it work with out MWM interpretation in mutter, which is btw. different from actual MWM behavior"
gtk3 is a "gnome first" toolkit and that shows. shrug
My suggestion would be to provide proper (or no) MWM support and have them deal with their rubbish.
Running after "we set some unspecified GDK* property" de touours (and depending on the presence of a compositor) is completely no option. At least I won't be available for such.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ftr, gtk3 does not create 32bit windows here (incl. compositing), so the decoration bugs are etiher false positives (there's a headerbar and the client actually supposed to be undecorated) or due to this bug in fluxbox (the reply on the bug where I asked suggests such, because a window w/o MWM hints should have a titlebar)
Ie. odds are high that the patch fixes the CSD related bugs
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mehhh...
https://github.com/luebking/fluxbox/commit/7ea57df7e8ca47f06f80b53d0d57f3f6652bb71b
so, the 7ea57df commit brings back invisible decorations, as complaint by so many for gtk3-apps?
My assumption is (could be argb issue, though) that gtk3 sets MWM to hide the deco (does) and then for some reason (plugin to fix the headerbar rubbish?) withdraws that hint.
Fluxbox correctly adheres to the former but would presently and wrongly ignore the latter.
The patch fixes that.
Whether that's the case I can't say (waiting for reply on the bug)
As long as gtk does set the "proper" MWM hint (and not withdraw it), the window will remain undecorated. This would only be "fixable" by "ignore MWM because shitty gtk abuses it" (what i'd personally not endorse at all)
However, at least here gtk3 sets the MWM hint only for windows which it provides a headerbar (incl. CSD), ie. such which are supposed to not be decorated by the WM.
the last time i started to examine the situation my conclusion was similar to yours: gtk3 "sets" / "removes" some props on the window and sometimes it's bad timing in the sense that fluxbox already provided the "functions" (to allow movement etc). the last time i checked i had a hard time to find some good documentation about how CSD is supposed to work at all.
It's not specified at all what is a major complaint. The strategy is "we make it work with out MWM interpretation in mutter, which is btw. different from actual MWM behavior"
gtk3 is a "gnome first" toolkit and that shows. shrug
My suggestion would be to provide proper (or no) MWM support and have them deal with their rubbish.
Running after "we set some unspecified GDK* property" de touours (and depending on the presence of a compositor) is completely no option. At least I won't be available for such.
yep, i agree. i just never dived deep enough into this rabbit hole to give "them" a reasoned "go away!" + the argument :)
propper mwm support seems fine.
ftr, gtk3 does not create 32bit windows here (incl. compositing), so the decoration bugs are etiher false positives (there's a headerbar and the client actually supposed to be undecorated) or due to this bug in fluxbox (the reply on the bug where I asked suggests such, because a window w/o MWM hints should have a titlebar)
Ie. odds are high that the patch fixes the CSD related bugs