Re: GTK+, WM, desktops and CSD

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 5 March 2015 at 17:51, Olivier Fourdan <fourdan gmail com> wrote:

> I am not one of them, but there are a lot of people (including KDE
> devs apparently) concerned about CSD because it means different
> decorations depending on the apps/toolkit => Consistency might suffer.

I don't strictly buy the "consistency" argument at all.

Right now, on my desktop, I have open two different browsers — Firefox
and Chrome — that do not look like anything on my desktop. I also have
an office suite using its own toolkit which passes a slight
resemblance to GTK, if I squint my eyes and tilt my head a bit. If I
were so inclined, I could be probably running some non-GTK
applications, and those would look fairly different.

There's no consistency because we're not running a platform with a
single toolkit.

If you're referring to the window controls, you can specify them even
for GTK windows using client-side decorations; it's a setting that can
be changed to reflect your environment — that's why both server-side
and client-side decorated GTK windows have the same buttons.

> I think it's very little change in GTK+ as it's already able to do
> both SSD and CSD (currently, decision to use CSD or SSD being made at
> run time based on the availability of a compositor).

That's not entirely correct. The decision to use client-side
decorations is up to the application developers, not to the toolkit.
An application developer may decide to support both the UIs, and opt
for client-side decorations if they detect that the application is
running under GNOME, but the toolkit is only tangentially involved.
The only place where GTK decides to use an header bar or not is for
the dialog windows it creates — file selection dialogs, print dialogs,
color selection dialogs, etc. Those are under the control of the
toolkit, so the toolkit can make a decision. The UI of an application,
on the other hand, is the remit of its developer. The toolkit cannot
really move widgets around, because it's missing context to do so. If
I use a GtkHeaderBar with a button at the top left, and the
environment does not support CSD properly, where should the toolkit
put that button? Keep the header bar, but still have decorations on
top, thus replicating things like titles?

Your proposal for an hint could be simply solved with a check on
whether the screen is composited (which is already available) and/or a
check on the desktop environment. Sure, we can add a freedesktop.org
spec that tells us if the application is running under GNOME, KDE,
XFCE, or whatever. Obviously, it all breaks apart as soon as "choice"
is factored in — if somebody is running under KDE with KWin without
compositing, what would the environment be? Same with XFCE running
with another window manager. Let's ignore that for a minute, though,
and figure out the issues of such a hint.

 • How does that hint get specified? Is it an X11 property on the root window?
 • How does it get monitored? What happens if the user changes the
setting at run time? Do we get a client message?
 • How are applications supposed to react when that setting is found,
or when it changes? Do they ship with two different UIs, one for CSD
and one for SSD?
 • What happens if the application does not have two UIs? Is the
setting ignored, and the application stays with client-side
decorations even if the window manager does not support the Motif WM
hints?

At the end of the day, though, if the application developer decides to
use a GtkHeaderBar and client-side decorations, it's the application
developer's prerogative to have their wish obeyed.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[ ] ebassi [ gmail com]