It's already possible to configure the controls on a client-side decoration; see:

  https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-decoration-layout

As for the behaviour of clicks:

  https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-titlebar-double-click
  https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-titlebar-middle-click
  https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-titlebar-right-click

You can either use gsettings in a GNOME-like environment, or you can use a settings.ini file under $XDG_CONFIG_HOME/gtk-3.0.

shading is not available for csd windows

> shading is not available for csd windows

And neither are mousebuttons 4-7 (i.e. scrollwheel) available for binding, so integration is still broken.

its not broken. it is limited to what we can and want to support here. I don't think there is much point in keeping this bug open. We are not going to go all in with making this über configurable

> We are not going to go all in with making this über configurable

I fully understand that sentiment in regard to extended bindings, but window shading is a pretty basic feature on the linux desktop, so I cannot really follow here how this would be 'über'.

Shading is a 'trick' that is easy to implement if you are a reparenting window manager. With client-side decorations, it would be a lot of work

By 'basic' I meant 'expected basic functionality', like maximizing or iconifying is.

Unfortunately I'm not really competent in C, or I would try myself.

It seems not too hard to implement, here is a shadable headerbar written in Python:

http://pastebin.com/nVxfuSXG

Of course it's raw and unpolished (and let the user resize the 'shaded' window, a problem I didn't really look into for this proof of concept), but given that the headerbar already has such a strong influence on size allocation, and the rest of the window is just a container (which is again filled while respecting the headerbar), I'd assume this should be doable on the toolkit level even easier than here on my client side example.

Corrected Version -> http://pastebin.com/janCiWnD

*** Bug 768211 has been marked as a duplicate of this bug. ***

*** Bug 772909 has been marked as a duplicate of this bug. ***

Can this CSD be disabled? So if I don't use GNOME 3, but XFCE, is there any way to use GTK 3 programs like evince with normal themed headers (not with preloaded library hacks and double headers) where e.g. a focused window looks like a focused window? Or should I just uninstall them in disgust just like MS Office in MS Windows? :(

(In reply to T-Gergely from comment #11)
> Can this CSD be disabled?

No; if an application is using client-side decorations (via an header bar widget) then the application developers have decided for a specific UI. Unless the application developers want to allow for two different UIs, you get what they wrote.

On Wayland, on the other hand, all GTK windows get client side decorations because that's what the windowing system expects; unless the compositor implements the KDE decoration discovery protocol, in which case GTK won't draw decorations at all — except for applications that use a custom header bar (see above).

> So if I don't use GNOME 3, but XFCE, is there any
> way to use GTK 3 programs like evince with normal themed headers (not with
> preloaded library hacks and double headers) where e.g. a focused window
> looks like a focused window?

Not unless the Evince developers wish to cater to your use case, and increase their maintenance burden by having two separate UIs.

> Or should I just uninstall them in disgust just
> like MS Office in MS Windows? :(

I strongly suggest you refrain from making this kind of comments on the GNOME project's bug tracker. You only get one warning.

(In reply to Daniel C. Würl from comment #7)
> By 'basic' I meant 'expected basic functionality', like maximizing or
> iconifying is.

Clearly you and I have very different concepts of "basic" window management features — and I have to admit that in 20 years of using X11-based desktops, I maybe used shading 3 times in total.

> I'd assume this should be doable on the toolkit level even easier than here
> on my client side example.

It really depends on a lot more: we need to expose a behaviour that was completely internal to the window manager.

The title bar that GTK uses on Wayland for top levels without custom controls could probably support shading, though in other to have the same behaviour we'd have to hide the rest of the UI, which would be a weird change for applications. X11 window managers can do this because they can literally hide the contents of the window without the application knowing; since decorations are client-side, it means a new window state — one that GTK currently does not have. In theory it would be possible to add it, even though GTK+ 3.x is now to be considered feature and API frozen.

This whole thing is even more critical for client side decorations with a custom GtkHeaderBar, because the application is in full control of the UI, so it's entirely up to it to decide how to appear when "shaded"; a media player could use the "shaded" state to change the controls and have a minimal UI, for instance.

So, in order to implement shading, we'd need:

 - a way for the window manager to tell us to go into "shaded" state; EWMH has a _NET_WM_STATE_SHADED atom for the _NET_WM_STATE property, which will need a Wayland counterpart, if one does not exist
 - a new GdkWindowState to match the 'shaded' state
 - code in GtkWindow to catch this new state and, when using client-side decorations, update the state of the GtkHeaderBar and hide the contents of the window
 - possibly some code in GtkHeaderBar (a property, maybe) that applications can catch and update the contents of the header bar widget in response of the new state

(In reply to Emmanuele Bassi (:ebassi) from comment #12)

> > Can this CSD be disabled?
> 
> No;

Thanks. I won't look for a solution for fixing these projects then as long as I have acceptable alternatives. I changed my default/legacy GTK Fedora apps with multiple regressions/problems to Pluma, qpdfview, Geeqie, Gnome Mines 2.32, Liferea 1.8.14, etc. Luckily, GIMP still works OK for me out of the box. I find it ironic (in a sad way) that even Java Swing apps (I didn't even suspect Ardunio IDE was one until I looked inside) look native on my preferred OS: GNU/Linux, but apps that I though were "native" do not.

I don't think there's anything to keep this bug open - we're not going to implement client-side shading, realistically.

Hi,

Sorry, the bug isn't that *shading* isn't supported, not any more, it's that a middle click on the title bar can only raise a window, nothing else.  Other people (me, for example) have reported in other bugs the broken state of other actions, like lowering the window.  Those other bugs got closed because they are, supposedly, duplicates of this one.  The claim has been that there is some single common design flaw that leads to none of these features working, and for whatever reason it was decided that this shading bug was going to be the torch bearer.  I don't know why.  I also don't care about shading, I care about my bug :-).

In any case, this isn't a debate about the philosophy of window management, whether something is "basic" or not, there is a configuration option that users can twiddle that does not function correctly.  That's a bug.  Gnome can't won't-fix it, and just leave broken configuration options, that's not an acceptable standard of software maintenance.

What I don't understand is if Gnome literally can no longer lower a window at all because Wayland is just that flawed, or if it's easily fixed and somebody simply forgot to hook up the plumbing, or if the feature's removal is deliberate and ideological because, I don't know, some Gnome developer had a bad 3-button mouse experience in their childhood.  For example, I don't really care about middle clicking on the title bar if that's the issue, I just want to be able to lower a window without one-by-one clicking everything behind it to raise them above it.  Right-clicking on the title bar brings up a menu of window movement options which could offer to lower the window.  Having to rely on that would not be ideal, but it would work.  There exists a keyboard shortcut setting to lower a window, which I could use, but no key binding is set by default, and, anyway, if it's possible to set a keyboard shortcut, or add the lower-this-window action to a menu, if that would work, if it is possible to lower a window at all, then surely the middle-click-title-bar-to-lower feature could just be fixed, no?

(In reply to Kipp from comment #16)
> Hi,
> 
> Sorry, the bug isn't that *shading* isn't supported,

The bug was open explicitly for shading.

> not any more, it's that a middle click on the title bar can only raise a window, nothing else.

This kind of configuration is offered on a per-backend basis, and only as a best effort.

On X11, you can configure client-side decorations to manipulate the stacking order: see the links I pasted in comment 1.

On Wayland, clients cannot know anything about the stacking order, as it's private to the window manager. This is by design, as it would allow random clients to manipulate the stacking order without user interaction.

Like I said about shading in comment 13, it would be possible to implement this functionality using a new Wayland interface, as an extension to the core Wayland protocols, just like we have xdg_shell or gtk_shell or the KDE negotiation interface for showing client-side decorations on Wayland; this would also require implementation in the toolkit and in the various Wayland-based display servers, so it would need to be discussed on the wayland-devel mailing list.

It's of course possible to re-design and re-implement all the functionality currently configurable on X11, but nobody on the GTK side, or the GNOME side, is going to work on that; if you want to contribute this functionality, feel free to do so, and re-open the bug once you have a patch.