Created attachment 5313 screenshot GTK+ uses mwm hints to implement client-side decorations and custom titlebars. In particular, we are asking for a border, but no titlebar. xfwm4 is so far the only window manager I've come across that supports mwm hints, but not this combination. Please consider supporting this. See the screenshot for the current, suboptimal user experience.
I've implemented support for this, the branch is available here: https://github.com/ali1234/xfwm4/tree/mwm2 It's a series of patches, as I had to change quite a few things.
Created attachment 5316 How it looks now
Great to see this, that was quite fast :) I have checked the last 5 commits, as I guess those are related, and looks OK.
Sorry for asking but why aren't those patches in git master yet? With Gtk+ 3.12 there are already a lot of CSD modal dialogs in most GTK+ 3 apps.
My laptop's dead again, someone else needs to review/push the patch..
I can't say I'm thrilled by the fact that the patch requires new decorations (not willing to redo all the themes). But more importantly I reckon GTK+ is doing it wrong TBH, not only by relying on a 20 year old spec to implement client-side decorations, but also by not doing client side decoration fully and still asking for the WM to draw the borders. Either the decorations are done by the client, all of the decorations and not just the title bar, or else the WM does it.
The patch does not require any new decorations. It can reuse the existing ones by flipping the bottom border pixmaps and drawing them at the top. This happens if the new decorations are missing. Adding new decorations is therefore optional for theme designers. I agree that Gtk+ is doing it wrong.
Also I moved the patches on to Xfce user repository: http://git.xfce.org/users/ajb/xfwm4/log/?h=mwm
(In reply to Alistair Buxton from comment #7) > The patch does not require any new decorations. It can reuse the existing > ones by flipping the bottom border pixmaps and drawing them at the top. This > happens if the new decorations are missing. Adding new decorations is > therefore optional for theme designers. Reusing, flipping, modifying existing themes pixmaps is a dead end, there's no way this can work reliably with most themes out there. I think for this particular case we should use a generic, unthemable minimalist decoration. Even a flat window without pixmap would do.
On the contrary, it works with all the xfwm default themes, all the themes shipped by default on ubuntu, and the top 10 most popular and most downloaded themes on xfce-look. In fact I cannot find a single theme it doesn't work with.
(In reply to Alistair Buxton from comment #10) > On the contrary, it works with all the xfwm default themes, all the themes > shipped by default on ubuntu, and the top 10 most popular and most > downloaded themes on xfce-look. In fact I cannot find a single theme it > doesn't work with. Unfortunately, it works with all the themes in Ubuntu is quite irrelevant here, can you show me a screenshot with the theme "R9X" for example? Note importantly, most themes borders reflect a Northwest light source, flipping pixmaps will break that visually (the devil's always in the details). That's why I would really prefer a much robust yet simple implementation in the sense of an unthemeable thin border for apps that specify border without title in MWM hints.
Created attachment 5434 r9x To me this looks fine. It's certainly better looking than an unthemable border, which will look bad with any theme. I think the only way this could look any better is by redo'ing the theme.
Also it is doubly-irrelevant for Ubuntu, because Ubuntu patched out headerbars from *everything* already. So we don't even need this patch.
That does look bad, shadows are upside down. Seriously, not sure what you mean about Ubuntu patches, but flipping pixmaps is no-go with me.
Please at least don't make the top borders unthemable, then nobody would update the themes so the work.
(In reply to ale.carrazzoni from comment #15) > Please at least don't make the top borders unthemable, then nobody would > update the themes so the work. Client-side decorations means the client app manages the decorations. All I'm saying is I see no point in doing dirty tricks to try to reuse the existing border pixmaps that will look wrong and out of the place anyway.
Not sure I agree that mwm hints being 20 years old is a valid excuse for not supporting them fully, or that GTK+ is somehow in the wrong for using them. But anyway, if you use GTK+ 3.12.1, you will actually get full csd decorations under xfwm4, aas long as compositing is enabled. I have taken out the check for _GTK_FRAME_EXTENTS support, which means that the shadow and invisible border will be treated as part of the window. Thats mainly noticable during interactive move or resize. But no more double titlebars. So, just turn on compositing.
Unfortunately not everyone can use compositing. I use compton instead of the xfwm compositor because otherwise JDownloader creates annoying artifacts on the top left corner. Also, the user shouldn't have to turn on an optional feature to make xfwm work properly with CSD.
(In reply to ale.carrazzoni from comment #18) > JDownloader creates annoying artifacts on the top left corner Disable the JDownloader tray icon. This is https://bugzilla.xfce.org/show_bug.cgi?id=10620
Is there any way to get around the app's client-side decoration and to use only the native WM's decorator?
I think that although CSD might be a good fit for GNOME they are problematic in Xfce for various well-known reasons: * CSD look out of place in a heterogeneous application environment (which is much more likely for Xfce than GNOME or KDE users since Xfce does not have such a broad range of "native" applications) where windows of applications using different toolkits such as GTK2 (most of Xfce for the time being), Qt, or Java are combined * xfwm4 has the ability to forcibly close windows of hung applications which is impossible with CSD and they cannot even be moved * xfwm4 allows to roll up a window, show a window on all workspaces or always keep it on the top layer, all of which is impossible with CSD * xfwm4 allows to customize the buttons shown in the titlebar, e.g. a button for pinng or rolling up windows, all of which is lost with CSD and leads to inconsistencies because such buttons are not even supported * xfwm4 allows to customize mouse actions on top of the window decorations such as double-clicking the title-bar or rolling up the window with the mouse-wheel, all of which is impossible with CSD Thus, CSD are IMO generally undesirable and unsuitable for Xfce and the above patch should not be merged. Rather, and not only because this affects Xfce but also setups which only use a window manager without a complete DE, or more importantly KDE, I think it is not unreasonable for asking the Gtk side to add a setting for disabling CSD. By that I mean not drawing its own border and hiding client window controls and disabling the MWM hints that disable the window manager's decorations. From reading about CSD on Matthias blog I figure that it is currently only possible to change the order of client side window controls and their appearance on dialog windows. Matthias, could you implement something like that as an xsetting? Our xfsettingsd could then use that setting to disable CSD by default when running an Xfce session.
Since GTK+ has removed a lot of settings later I wouldn't trust them to add a setting for us. Alistair: I really need JDownloader in the tray area. I'd like to fix that bug in Xfwm but sadly I don't know how X Window Managers work.
> xfwm4 is so far the only window manager I've come across that supports mwm hints, but not this combination. Just for the record: KWin doesn't support this combination, either (see https://bugzilla.gnome.org/show_bug.cgi?id=729769) and our investigation showed that there are lots more window managers not supporting it. In KWin we are not going to add support for this as it cannot be implemented in a way that ensures that the decoration doesn't draw it. As MWM hints do not allow the WM to tell what it supports, it doesn't make much sense to invest time in a solution which would be incomplete from the start.
So it should be fixed in GTK+ then?
(In reply to ale.carrazzoni from comment #24) > So it should be fixed in GTK+ then? The bug is valid and we /{c,s}hould/ support the hints, I just find unfortunate that GTK+ relies on such a mechanism. Anyhow, as we have a patch ready thanks to Alistair, I agree that patch should be merged.
(In reply to Olivier Fourdan from comment #25) > (In reply to ale.carrazzoni from comment #24) > > So it should be fixed in GTK+ then? > > ... I just find > unfortunate that GTK+ relies on such a mechanism. Exactly, so if you merge it, can you for this reason please add a wm tweak setting to enforce window decorations, i.e. keep the status quo? > Anyhow, as we have a patch ready thanks to Alistair, I agree that patch > should be merged. So what about the theming issue, do you wan to go with the flipped pixmaps? You also didn't comment on the issue Martin raised? @Matthias: Could give some feedback on a possible solution from the GTK side for non-GNOME environments where CSDs doe not fit well, especially my suggestion in comment#21? If needed I can also open a RFE on the GTK bugtracker to discuss this further.
(In reply to Matthias Clasen from comment #17) > Not sure I agree that mwm hints being 20 years old is a valid excuse for not > supporting them fully, or that GTK+ is somehow in the wrong for using them. > > But anyway, if you use GTK+ 3.12.1, you will actually get full csd > decorations under xfwm4, aas long as compositing is enabled. I have taken > out the check for _GTK_FRAME_EXTENTS support, which means that the shadow > and invisible border will be treated as part of the window. Thats mainly > noticable during interactive move or resize. But no more double titlebars. > > So, just turn on compositing. Great, now tiling is broken when compositing is turned on. It's even worse when using compton since you have a double shadow. Can't you just draw a window properly?
(In reply to ale.carrazzoni from comment #27) > Great, now tiling is broken when compositing is turned on. Unrelated to this current bug, please don't confuse things even more with this current issue. > It's even worse > when using compton since you have a double shadow. Can't you just draw a > window properly? If you are using Compton, it's a bug in Compton, not in Xfce nor in GTK+. But again, this is unrelated to the current issue, such comment just keep adding noise to an already fairly long bug which should be fairly straightforward: - Xfce does not support some combination of MWM hints - that was on purposed as I reckoned those should not be needed - we have now a patch, do we merge it or does it need rework before being merged.
I tend to agree with comment#21. Even if you merge the change, please support a way of enforcing normal decorations and turning CSD off. This stuff may look [questionably] good in Gnome, but I would never want to see it in Xfce. I would hate to realize I switched from Gnome 3 to Xfce just to find myself in the same place UX-wise a few years later.
Just for the record: The following bug is a collection of all issues with GTK's CSD: https://bugzilla.gnome.org/show_bug.cgi?id=729721 Martin proposed a IMHO useful plan for handling CSD outside GNOME there.
In GTK+ 3.14 about boxes and settings screens now have normal decorations but apps that use CSD (Evince and baobab at least) are still broken when compositing is turned off.
Fixed in gtk instead.