The GNOME bugzilla URL summarizes the situation quite well. Matthias Clasen [gtk+ developer] asserts that the problem is fixed but it's not. I can replicate what Mr. Clasen refers to a "double header" on KDE SC versions 4.11.8, 4.12.4 and now 4.13.0. Reproducible: Always Steps to Reproduce: 1. Upgrade from GTK+-3.10.2 to the current GTK+-3.12.1 2. Launch any application linked to libg[dt]k-3.so.0 3. You'll see the redundant text shown in my GNOME bugzilla attachments. Also see these links: https://mail.gnome.org/archives/gtkmm-list/2014-April/msg00003.html http://gtk.10911.n7.nabble.com/Titles-in-Gtk-Dialogs-td84196.html My perception is that the GTK developers deal with GNOME and since the problem doesn't happen on that DE, they've marked it RESOLVED/FIXED. The rolling release, Arch Linux, has just upgraded to GTK+-3.12.1 and the problem is evident there as well as on my Linux from Scratch System. The fact that the "double headers" also exist on XFCE4 and even TWM make me dubious of Mr. Clasen's claim of it being FIXED. On the other hand, Kjell Ahlstedt in his post of Apr 09, 2014; 1:30pm states: If the window manager accepts not to add a titlebar, the result is as in the attachment to msg00001.html. I don't consider it an improvement from earlier versions of gtk+, where only the window manager added a titlebar, but it's obviously a deliberate modification. Gtk+ wants to take the whole responsibility for the look of dialog boxes.
Why are you reporting GTK bugs to the Plasma bug tracker? Applications trying to add their own title bars (called "client side decorations") have to request the proper NETWM flags to hide the title bar that is added by the window manager.
In the case of GTK it's quite simple: if not run in GNOME environment they should not add their own titles. This needs clearly fixing on the GTK side. We cannot do anything if GTK devs decide to break their applications on any non GNOME environment.
apparently fixed in gtk3 3.12.1 (at least), which sets the proper MWM hints, the former version had the MWM hints, but set MWM_DECOR_BORDER (only and esp. w/o MWM_DECOR_ALL) But the MWM hints ain't too complex, no way. Never. Sure. m(
Created attachment 86153 [details] updated mwminfo btw, i think the lat mwminfo tool i sent around had a bug. oh, and it REALLY sucks to have the close button on the wrong side of some windows now (actually it's luckily just gtk3-demo & zenity - for now...)
> oh, and it REALLY sucks to have the close button on the wrong side of some > windows now (actually it's luckily just gtk3-demo & zenity - for now...) If that becomes worse I'm really thinking we should just remove motif support. Will create double borders, but maybe it's enough to trigger the thinking that they shouldn't break integration with other environments. I kind of understand why Ubuntu starts to fork the GNOME applications to provide an integrated look and feel.
They're the only gtk3 apps i've installed - i assume it will affect all dialogs. There's more issue because of _GTK_FRAME_EXTENTS(CARDINAL) = 29, 29, 27, 31 The window is ARGB with internal shadows (of fixed size and color...) and w/o interpreting the value, we've a) Alt+F3 menu in wrong position b) an enforced titlebar padded around the visible window (and shadows twice), (input-)shaped between window and deco c) trouble with snapping ;-)
(In reply to comment #1) > Why are you reporting GTK bugs to the Plasma bug tracker? Applications > trying to add their own title bars (called "client side decorations") have > to request the proper NETWM flags to hide the title bar that is added by the > window manager. Because the GTK developer, Matthias Clasen, implies that the problem is due to the WM not handling the GTK request to suppress those CSD: https://git.gnome.org/browse/gtk+/commit/?id=fb9a6bb6d8d6b60b25c9b9853decbc http://ftp.gnome.org/pub/gnome/sources/gtk+/3.12/gtk+-3.12.1.newsea938f7863
(In reply to comment #6) > They're the only gtk3 apps i've installed - i assume it will affect all > dialogs. All dialogs created by GTK+-3.12.1 are indeed affected.
Using the updated "mwminfo" tool, here's an A/B comparision between two versions of gtk3-demo build with the corresponding shared libraries: 1). gtk3-demo (GTK+-3.10.8) Seems no _MOTIF_WM_HINTS are provided, try 'xprop _MOTIF_WM_HINTS' for verification 2). gtk3-demo (GTK+-3.12.1) 0x2 0x0 0x2 0x0 Only the fields mentioned in the first field are to be considered NOTICE that MWM_*_ALL indicates to DISABLE either ALL items or the ones passed in addition! -------------------------------------------------------------- 1: MWM_HINTS_DECORATIONS 2: 3: MWM_DECOR_BORDER 4: MWM_INPUT_MODELESS From the political angle, it appears that the GTK developers are washing their hands of this and blaming the WM. And at least one KDE developer is irked that I even brought the matter up, citing it as breakage on the GTK side. And I see that the status here was changed to "RESOLVED/INVALID" not dissimilar to the GTK bugzilla site marking BUG #727414 as "RESOLVED/FIXED".
(In reply to comment #9) > 2). gtk3-demo (GTK+-3.12.1) > 0x2 > 0x0 > 0x2 > 0x0 > -------------------------------------------------------------- > 1: MWM_HINTS_DECORATIONS > 2: > 3: MWM_DECOR_BORDER > 4: MWM_INPUT_MODELESS This says: please add a border w/o minimize/maximize/close button (just that kwin ignores button requests by MWM hints, sharing a meatcity statement that deemed them "stupid") It's however not the hints I get here atm., which is: 0x2 0x0 0x0 0x0 Only the fields mentioned in the first field are to be considered NOTICE that MWM_*_ALL indicates to DISABLE either ALL items or the ones passed in addition! -------------------------------------------------------------- 1: MWM_HINTS_DECORATIONS 2: 3: 4: MWM_INPUT_MODELESS and says: "please no border" (ie. the correct variant) as does eg. chromium when using the resp. mode. I'll try a reboot since i tried this under other WMs and I don't know whether gtk caches capabilities between processes and might use the proper mode depending on random WM exports. -- I don't think that Christoph is "irked" about you bringing up the bug here, if at all perhaps just in a generally pissed mood because of the CSD nonsense ;-)
Created attachment 86158 [details] Simple GTK dialog example
I understand about the feelings on the KDE side and as a longtime partisan of KDE (going back to the version 1 days), I don't think anything will get me to use another DE. To provide some context, I first noticed the problem in emacs when I used the menu to exit and saw the "double header". 99% of the time, I use "C-x C-c" to leave so I never see dialogs. On the one time I did, I noticed the frame showing "Question" and the content of the dialog box also showing "Question". That's what piqued my curiosity and prompted me to submit it as GTK bug. I have a simple toy which requires the gtkmm C++ bindings that may make it a bit easier to distill the problem into its raw essence.
Apropos the "Simple GTK dialog example", for those just visiting this thread out of curiosity, the compilation command is: g++ gtk-dialog.cc $(pkg-config --cflags --libs gtkmm-3.0) By the way, it's easy for me to provide whatever information may be of interest since I have several virtual machines available, all with KDE SC, and some with GTK in the 3.10.X version series and some with GTK 3.12.1. Applying Occam's razor, the finger points to GTK since the problem first arose when I upgraded the GTK3 package and changed nothing on the KDE side. To reiterate, I only brought the matter up here since Matthias Clasen over on the GTK side considers it closed on his end.
twm doesn't support MWM hints, so it won't hide the titlebar of any client however, i've made an "interesting" observation: Starting gtk3-demo under twm leads to "0x2 0x0 0x2 0x0" (which is wrong - if gtk detects MWM support, it would reasonably not set any hints. And that particular hint somehow makes no sense at all) The hint is not updated w/ the WM. Starting under kwin results in "0x2 0x0 0x0 0x0" (which is a proper MWM way to say: no border please) The hint is not updated w/ the WM, but gtk does seem to change the value along the WM or its exports and that's not related to caching (didn't reboot so far) Likewise starting w/o any WM results in wrong "0x2 0x0 0x2 0x0" as well and starting a WM doesn't alter the hints (as expected) I do not know why gtk would use different hints and set (the wrong) one if there's no WM (any hint is pointless and the WM is not predictable) -> Can you please post the output of xprop -root _NET_SUPPORTED Semi-OT About CSD: it's not somehow a "GNOME vs. KDE wars" thing, but considered wrong by myself (and I know at least Martin shares that opinion ;-) See http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with-client-side-window-decorations/ for various concerns. I'm not sure that this will remain a dialog item, afaiu it's a general conceptual choice.
(In reply to comment #14) > Semi-OT About CSD: > it's not somehow a "GNOME vs. KDE wars" thing, but considered wrong by > myself (and I know at least Martin shares that opinion ;-) > See > http://blog.martin-graesslin.com/blog/2010/05/open-letter-the-issues-with- > client-side-window-decorations/ for various concerns. > > I'm not sure that this will remain a dialog item, afaiu it's a general > conceptual choice. As the instigator of this, that link to Marin Gräßlin's blog was *very* worthwhile reading. No matter where this issue goes, one way or another, becoming aware of that on-point essay was worth it. Thank you much for that link, it's a real eye-opener.
Created attachment 86161 [details] xprop -root _NET_SUPPORTED results The tarball shows the results, as requested, of this command on 6 different WMs: xprop -root _NET_SUPPORTED kde3.5.10 kde4.13.0 (kde-workspace 4.11.8) mwm-2.3.4 twm-1.0.8 gnome from Ubuntu 14.04 LTS xfce4 (xfwm4.10.1) I can provide anything else requested and I hope this is useful.
(In reply to comment #14) > however, i've made an "interesting" observation: > > Starting gtk3-demo under twm leads to "0x2 0x0 0x2 0x0" (which is wrong - if > gtk detects MWM support, it would reasonably not set any hints. And that > particular hint somehow makes no sense at all) > The hint is not updated w/ the WM. > > Starting under kwin results in "0x2 0x0 0x0 0x0" (which is a proper MWM way > to say: no border please) My results are different with gtk3-demo (from the 3.12.1 package). In all cases, the result from "mwminfo" is "0x2 0x0 0x2 0x0". I've tested this on the following WMs: kde3.5.10 kde4-12.4 (with kde-workspace 4.11.8) kde4-13.0 (with kde-workspace 4.11.8) mwm-2.3.4 twm-1.0.8 xfce4 (xfwm4.10.1) ...and, for what it's worth, I also rolled back to GTK 3.12.0, the version before the "double header" patch and the results were the same, "0x2 0x0 0x2 0x0". I have yet to get a result of "0x2 0x0 0x0 0x0" either with gtk3-demo or the little toy program using gtkmm. I hope this isn't information overloaded with so much data coming from me over the pasts few posts as I boot into both "bare metal" and VirtualBox systems to explore this.
D'OH! I should have looked at the screenshot before - it's the lack of compositing! Suspending the KWin compositor (Shift+Alt+F12) i can perfectly cause the "wrong" MWM hint. Apparently gtk makes the presence of a compositor the determinant and I see why: it technically asks for a border (MWM_DECOR_BORDER) and not a titlebar (MWM_DECOR_TITLE), ie. it really only wants a rectangle with resize handles, but KWin (ever since) takes that as border+titlebar (esp. since it has no API to tell decoration plugins to add a border but no titlebar) In a composited environment it doesn't require a border, since it provides an ARGB window with resize management in the "shadow" regions. Why it doesn't just use the outer pixels of the dialog to trigger resizes (as would be consistent w/ CSD, i assume?) i don't know. We meanwhile might be able to use the input window (invisible resize handles) and omit the border in this case...
(In reply to comment #18) > D'OH! > I should have looked at the screenshot before - it's the lack of compositing! > > Suspending the KWin compositor (Shift+Alt+F12) i can perfectly cause the > "wrong" MWM hint. And a double-DOH from here in the states! :) You indeed nailed it. Enabling "Desktop Effects" has the desired effect, in this case, of suppressing the titlebar and frame. And it logically follows that "mwminfo" then reports "0x2 0x0 0x0 0x" when compositing is enabled. Sorry to cause such a ruckus here in this forum and I thank all involved for their diligence and, course, intelligence.
> it has no API to tell decoration plugins to add a border but no titlebar Does that imply decoration API has to be added to fix this bug? > I don't think that Christoph is "irked" about you bringing up the bug here, if at all perhaps just in a generally pissed mood because of the CSD nonsense ;-) I assumed there was only a single way to request "no borders", which obviously was working since ever. Otherwise, you are correct ;)
(In reply to comment #18) > I should have looked at the screenshot before - it's the lack of compositing! Just curiously, what was apparent in the screenshot revealing non-compositing? The lack of active glow or was it something else more subtle?
The round decoration corners are aliased :-)
(In reply to comment #22) > The round decoration corners are aliased :-) Thanks...I'll wrap my participation in this thread (unless there's anything where I can be of help) with the observation that you have *very* good eyes! :) I appreciate all of the KDE wizards for not only their posts in this thread but for all the work over the years. KDE has been my constant DE. Sure, I've explored others from time to time, but at the end of the day, nothing else comes close.
(In reply to comment #20) > > it has no API to tell decoration plugins to add a border but no titlebar > > Does that imply decoration API has to be added to fix this bug? yes, though this is problematic. We would need to add this to the decoration API and expect that the decoration plugins implement it. This can be done for native plugins we ship - e.g. Oxygen. But it becomes really difficult for themed plugins, like deKorator, QtCurve or Aurorae. I'm most familiar with Aurorae and there we cannot just remove the areas without breaking the theme. Thus it needs an API which provides Abilities. The plugin would have to set the Ability whether it supports it or not. And then KWin would have to provide the supported information just that there is no supported in the MWM hints case. We are not able to tell the outside world that the plugin cannot do it. Which makes it questionable to implement support for it. Why implement something which would only work sometimes or depending on the theme which is used? To me this sounds like a WONTFIX. This needs a proper NETWM specification and GTK needs to honor it. If we go for a NETWM spec we don't have to adjust anything on our side, because GTK would honor that we don't set the hints.
*** Bug 342853 has been marked as a duplicate of this bug. ***
re-opening as wish. NOTICE: that concerns from comment #24 remain, though.
The "double header" problem is back with GTK+-3.16.0. The most recent GTK version that behaves normally is GTK+3.14.10. I'm sticking with that older version since the redundant titles are distracting. FWIW, the "double headers" also occur on KF5 5.8.0/Plasma-5.2.2 with that newest GTK version.
Yes that is an intended change in GTK to fix breaking in general, unfortunately it exposes this problem :-(
They seem to think (wrongly IMHO) that all the world is GNOME. The reality is that GTK+-3 is used by a number of apps and enforcing their notion of CSD when it's unwanted is very short-sighted on their part. But that's politics and thus ends my rant targeted at the GNOME/GTK designers.
(In reply to Martin Gräßlin from comment #28) > Yes that is an intended change in GTK to fix breaking in general, > unfortunately it exposes this problem :-( It was addressed in the just-released gtk+-3.16.1 tarball. Here's a snip from the ChangeLog bundled in the package: Improve CSD decorations without a compositor It turned out that using mwm hints to instruct wms to create border-only decorations is not really working universally. So, instead of doing this, render a solid frame without shadow on the client-side to handle this case. https://bugzilla.gnome.org/show_bug.cgi?id=746222