Add support for title-less windows

Bug #1301873 reported by Thaddaeus Tintenfisch
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Xfwm4
Won't Fix
Medium
xfwm4 (Debian)
Fix Released
Unknown
xfwm4 (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Allow windows which request no title to get a border at the top instead.

Experimental upstream branch:
http://git.xfce.org/users/ajb/xfwm4/

Tags: trusty
Revision history for this message
In , Matthias Clasen (matthias-clasen) wrote :

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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

Created attachment 5316
How it looks now

Revision history for this message
In , Robert Roth (evfool) wrote :

Great to see this, that was quite fast :) I have checked the last 5 commits, as I guess those are related, and looks OK.

Changed in xfwm4:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

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.

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

My laptop's dead again, someone else needs to review/push the patch..

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

Also I moved the patches on to Xfce user repository:

http://git.xfce.org/users/ajb/xfwm4/log/?h=mwm

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

(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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

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.

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

(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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

Also it is doubly-irrelevant for Ubuntu, because Ubuntu patched out headerbars from *everything* already. So we don't even need this patch.

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

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.

Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

Please at least don't make the top borders unthemable, then nobody would update the themes so the work.

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

(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.

Revision history for this message
In , Matthias Clasen (matthias-clasen) wrote :

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.

Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

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.

Revision history for this message
In , Alistair Buxton (a-j-buxton) wrote :

(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

Revision history for this message
In , scar (arch-scar) wrote :

Is there any way to get around the app's client-side decoration and to use only the native WM's decorator?

Revision history for this message
In , Guido Berhoerster (gber) wrote :

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.

Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

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.

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

> 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.

Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

So it should be fixed in GTK+ then?

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

(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.

Revision history for this message
In , Guido Berhoerster (gber) wrote :

(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.

Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

(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?

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

(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.

Revision history for this message
Ang Bongsong (notinsideofhereiamnotinside) wrote :

Just filed what appears to be a related bug here: https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1328244
If it's a duplicate, let me apologize in advance. I couldn't be sure. Hoping it's not though.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfwm4 (Ubuntu):
status: New → Confirmed
Revision history for this message
Ang Bongsong (notinsideofhereiamnotinside) wrote :

Just adding some screenshots that exemplify the issue.

Deja Dup: http://i5.minus.com/iS7enWsFloCjG.png
Archive Manager: http://i4.minus.com/iznC4vTbwkEp9.png
Disks: http://i2.minus.com/iFPvm9XYQEIB1.png
A proper window for reference (Thunar): http://i5.minus.com/ib2jflseAk1Ug1.png

I'm sure you notice the problem here. Those are all Gtk3 applications by the way.

Changed in xfwm4 (Debian):
status: Unknown → New
Revision history for this message
In , Mike Gelfand (mike.dld) wrote :

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.

Revision history for this message
In , Olaf Leidinger (oleid) wrote :

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.

Revision history for this message
In , Magnus (ale-carrazzoni) wrote :

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.

Revision history for this message
Roman (thezub) wrote :

This is also broken in KDE, by the way, but this shouldn't be reported to Xfce - it's not their fault. This is GNOME's fault for thinking my desktop is a smartphone. The window manager needs to be drawing the title bar, and you can implement any custom options in the application itself.

Jackson Doak (noskcaj)
Changed in xfwm4 (Ubuntu):
importance: Undecided → Wishlist
Changed in xfwm4 (Debian):
status: New → Fix Released
Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

Fixed in gtk instead.

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

This should be fixed in Ubuntu 14.10 and up.

Changed in xfwm4 (Ubuntu):
status: Confirmed → Fix Released
Changed in xfwm4:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.