1419456 - Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER

Status: RESOLVED FIXED

(Core :: Widget: Gtk, enhancement)

Description

[Martin Stránský [:stransky] (ni? me)]

Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER. GDK_DECOR_BORDER causes the titlebar is shown on XFCE.

Comment 1

[mirh]

Does this apply even to latest gtk3-ported code (still only on git for now afaik)?

Comment 2

[Martin Stránský [:stransky] (ni? me)]

(In reply to mirh from comment #1)
> Does this apply even to latest gtk3-ported code (still only on git for now
> afaik)?

If you mean https://github.com/stransky/gecko-dev/tree/titlebar-csd it contains the same code as mozilla-central now.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1419456 - Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER,

Review commit: https://reviewboard.mozilla.org/r/201700/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/201700/

Comment 4

[mirh]

Lol, no. 
I was talking about *xfce* gtk3 version. https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html

And should that work (or even already work), a 'dumb' check just on the DE name would feel lame.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

(In reply to mirh from comment #4)
> Lol, no. 
> I was talking about *xfce* gtk3 version.
> https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> 
> And should that work (or even already work), a 'dumb' check just on the DE
> name would feel lame.

Sorry, I do my best. Feel free to provide better patch here, experts are always welcome.

Comment 6

[Jan Horak [:jhorak]]

Comment on attachment 8930595 [details]
Bug 1419456 - Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER,

https://reviewboard.mozilla.org/r/201700/#review207348

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/af8727e2028e
Disable full CSD support for XFCE as it does not support GDK_DECOR_BORDER, r=jhorak

Comment 8

[mirh]

(In reply to Martin Stránský [:stransky] from comment #5)
> (In reply to mirh from comment #4)
> > Lol, no. 
> > I was talking about *xfce* gtk3 version.
> > https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> > 
> > And should that work (or even already work), a 'dumb' check just on the DE
> > name would feel lame.
> 
> Sorry, I do my best. Feel free to provide better patch here, experts are
> always welcome.

I hope I'm not ccing the wrong folks

Comment 9

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/af8727e2028e

Comment 10

[Azari]

(In reply to mirh from comment #4)
> I was talking about *xfce* gtk3 version.
> https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> 
> And should that work (or even already work), a 'dumb' check just on the DE
> name would feel lame.

I think this bug is related to bug 1417933 comment 23 (and 24 for that matter), where Martin notes that to make this work in other window managers will require client-side resizers.

So presumably this bug to disable it on Xfce is just temporary until that other work is finished, which may land at a later date and end up being a fallback for window managers that don't support GDK_DECOR_BORDER.

This is just speculation on my part, but that's how I'm seeing the current situation.

Comment 11

[mirh]

Yeah, I had got that. 
Just indeed I wasn't sure on whether xfce in-progress gtk3 port was already good enough to works good with it, or not. 

But I would assume you'd need a version-based "blacklist" for every DE eventually.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

(In reply to Azari from comment #10)
> (In reply to mirh from comment #4)
> > I was talking about *xfce* gtk3 version.
> > https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> > 
> > And should that work (or even already work), a 'dumb' check just on the DE
> > name would feel lame.
> 
> I think this bug is related to bug 1417933 comment 23 (and 24 for that
> matter), where Martin notes that to make this work in other window managers
> will require client-side resizers.
> 
> So presumably this bug to disable it on Xfce is just temporary until that
> other work is finished, which may land at a later date and end up being a
> fallback for window managers that don't support GDK_DECOR_BORDER.

Titlebar should be hiden when browser.tabs.drawInTitlebar is set on XFCE. But as the GDK_DECOR_BORDER fallback is not implemented yet you'll miss resizers on main window.

Comment 13

[Martin Stránský [:stransky] (ni? me)]

(In reply to Martin Stránský [:stransky] from comment #12)
> (In reply to Azari from comment #10)
> > (In reply to mirh from comment #4)
> > > I was talking about *xfce* gtk3 version.
> > > https://blog.alteroot.org/articles/2017-05-30/road-to-xfce-4.14-part-2.html
> > > 
> > > And should that work (or even already work), a 'dumb' check just on the DE
> > > name would feel lame.
> > 
> > I think this bug is related to bug 1417933 comment 23 (and 24 for that
> > matter), where Martin notes that to make this work in other window managers
> > will require client-side resizers.
> > 
> > So presumably this bug to disable it on Xfce is just temporary until that
> > other work is finished, which may land at a later date and end up being a
> > fallback for window managers that don't support GDK_DECOR_BORDER.
> 
> Titlebar should be hiden when browser.tabs.drawInTitlebar is set on XFCE.
> But as the GDK_DECOR_BORDER fallback is not implemented yet you'll miss
> resizers on main window.

Sorry, I you need to also set widget.allow-client-side-decoration before Bug 1420110 lands.

Comment 14

[Azari]

(In reply to mirh from comment #11)
> Yeah, I had got that. 
> Just indeed I wasn't sure on whether xfce in-progress gtk3 port was already
> good enough to works good with it, or not. 

I'm not sure exactly how Xfce's window manager works, but since this is a WM-specific bug, they'd have had to change the window manager to add support for GDK_DECOR_BORDER; I would've imagined that the gtk3 work they are doing right now is more about porting their panel, settings app, and other applications to gtk3, since at the moment I don't think they're using gtk at all for the window manager, so they may not have any reason to modify it (at least not until the wayland port).

I guess someone would have to look at it, but by the time that version of Xfce is released, I imagine Bug 1420841 will have been fixed, since Xfce tends to have long dev cycles.

Comment 15

[Olivier Fourdan]

(In reply to Azari from comment #14)
> (In reply to mirh from comment #11)
> > Yeah, I had got that. 
> > Just indeed I wasn't sure on whether xfce in-progress gtk3 port was already
> > good enough to works good with it, or not. 
> 
> I'm not sure exactly how Xfce's window manager works, but since this is a
> WM-specific bug, they'd have had to change the window manager to add support
> for GDK_DECOR_BORDER; I would've imagined that the gtk3 work they are doing
> right now is more about porting their panel, settings app, and other
> applications to gtk3, since at the moment I don't think they're using gtk at
> all for the window manager, so they may not have any reason to modify it (at
> least not until the wayland port).

Thanks for taking the time to look into this and trying to make Firefox work the best on xfce, much appreciated.

I have just a couple of comments that, I hope, will help clarifying the current position.

Despite it's name (GDK_DECOR_BORDER), this is a Motif WM hint (MWH_HINTS), i.e. something like 20+ years old. MWM_HINTS allowed to define which part of the WM decorations should be drawn by the window manager, that included the title bar, resize frame, buttons, etc.

xfwm4 has support for this, but only partially (just like kwin actually), i.e. it doesn't decorrelate the titlebar from the rest of the frame, meaning it's all or nothing. One reason for this is that modern (as in supporting EWMH) X11 clients would define a semantic using NET_WM_WINDOW_TYPE and the window manager would remain in control on how to decorate the client window based on that semantic, so that the desktop remains consistent, as opposed to the older approach taken by Motif where the client would specify which bits of its decoration to draw, which led to all sorts of abuse and inconsistencies between applications.

Nowadays, apart from these older Motif applications, there is actually very seldom use for this anyway, client side decorations (CSD for short) is certainly not one of them. CSD means the client does all the work, it should not depend on the window manager for decorating /some/ of the frame. FWIW, gtk+ has support for this and is perfectly capable of doing CSD without it.

As for Wayland, this is an entirely different architecture, protocol, etc. which require a complete rewrite of a display server within the compositor, a tremendous amount of work, not something which is planned for xfce because we simply do not have the manpower for this, any time soon, if ever (the port of xfce to gtk3 is completely unrelated to Wayland, and being ported to gtk3 which has a gdk Wayland backend for the clients doesn't imply we magically get a Wayland compositor for free).

> I guess someone would have to look at it, but by the time that version of
> Xfce is released, I imagine Bug 1420841 will have been fixed, since Xfce
> tends to have long dev cycles.

So long story short, I reckon an X11 client willing to achieve client side decorations should draw *all* of the decorations, whereas one willing to remain with server side decorations should rely on the window manager for all of its decorations, and clients should not mix the two.

Comment 16

[Martin Stránský [:stransky] (ni? me)]

(In reply to Olivier Fourdan from comment #15)
> Nowadays, apart from these older Motif applications, there is actually very
> seldom use for this anyway, client side decorations (CSD for short) is
> certainly not one of them. CSD means the client does all the work, it should
> not depend on the window manager for decorating /some/ of the frame. FWIW,
> gtk+ has support for this and is perfectly capable of doing CSD without it.
> 
[...]
> 
> So long story short, I reckon an X11 client willing to achieve client side
> decorations should draw *all* of the decorations, whereas one willing to
> remain with server side decorations should rely on the window manager for
> all of its decorations, and clients should not mix the two.

Yes, I understand. What we want at Firefox is to have our own titlebar rendered by Firefox (by styles) and we don't care about the CSD shadows (borders, resizers) around the window. So we want Gtk to draw/handle CSD shadows/borders and resize the windows but don't draw GtkTitleBar widget. Is that possible? [1].

Also unfortunately Gtk is missing something like WM_NCHITTEST [2] which is used on Windows which also complicates things for us.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1420841#c2
[1] https://msdn.microsoft.com/cs-cz/library/windows/desktop/ms645618(v=vs.85).aspx

Comment 17

[Karl Tomlinson (:karlt)]

Attachment: GTK CSD demo without titlebar

Quality, including shadows, is dependent on _GTK_FRAME_EXTENTS and other things, but resizing is available even without _GTK_FRAME_EXTENTS.

Comment 18

[Karl Tomlinson (:karlt)]

Where GDK_DECOR_BORDER works, I'm guessing it is better than GTK CSD, as it would provide a more native experience and avoid the usual CSD problems tracked at https://bugzilla.gnome.org/show_bug.cgi?id=729721
(I don't know whether or not there are enough systems where GDK_DECOR_BORDER works to justify supporting that configuration.)

Comment 19

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (:karlt) from comment #18)
> Where GDK_DECOR_BORDER works, I'm guessing it is better than GTK CSD, as it
> would provide a more native experience and avoid the usual CSD problems
> tracked at https://bugzilla.gnome.org/show_bug.cgi?id=729721
> (I don't know whether or not there are enough systems where GDK_DECOR_BORDER
> works to justify supporting that configuration.)

I agree with you. This setup reliably works on gnome-shell and Cinamon which is IMHO majority of Gtk applications now as Ubuntu switched to gnome-shell at 17.10 (AFAIK). I didn't test Unity - adding to my TODO list.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (:karlt) from comment #17)
> Created attachment 8932675 [details]
> GTK CSD demo without titlebar
> 
> Quality, including shadows, is dependent on _GTK_FRAME_EXTENTS and other
> things, but resizing is available even without _GTK_FRAME_EXTENTS.

That's really great to see this working! I tested this approach some time ago and it didn't work - maybe I used wrong widget as the titlebar replacement.

Comment 21

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (:karlt) from comment #17)
> Created attachment 8932675 [details]
> GTK CSD demo without titlebar
> 
> Quality, including shadows, is dependent on _GTK_FRAME_EXTENTS and other
> things, but resizing is available even without _GTK_FRAME_EXTENTS.

gtk_window_set_titlebar() works only for unrealized widget which complicates it. We may need to enable that early or unrealize mShell on the fly. The latter (if implemented) needs extra care as Gtk tends to unrealize mContainer and hide the main toplevel window.

Comment 22

[Martin Stránský [:stransky] (ni? me)]

gtk_window_set_titlebar() solution filed as Bug 1421974