Bug#744249: libgtk-3-0: gtk 3.12 breaks usability by forcing client side decorations on X11

[Simon McVittie]

On 13/10/14 12:00, Vlad Orlov wrote:
>> I don't know about gthumb but gnome-calculator, devhelp, gedit and totem are
>> Gnome apps.
> 
> Yes, they come from Gnome project but that doesn't mean that the users of other
> desktop environments don't use them.

("you" in this email refers to anyone wanting fewer CSDs, not
necessarily any specific person.)

Looking at the GtkHeaderBar source code, it does not appear to be the
case that Gtk is "forcing client side decorations". 3.12 did for
GtkDialog under at least some circumstances, but 3.14 does not appear to
use CSD for GtkDialog under non-GNOME. Apps that use CSDs in X11 do so
because they specifically asked for it, e.g. Evince:

    gtk_header_bar_set_show_close_button (
        GTK_HEADER_BAR (ev_window->priv->toolbar), TRUE);
    gtk_window_set_titlebar (GTK_WINDOW (ev_window),
        ev_window->priv->toolbar);

So I'm inclined to close this as "valid bug in 3.12, fixed in 3.14".
It's clearly not a bug that Gtk uses CSDs when apps call the functions
whose documentation can be paraphrased to "please use CSDs here":

    If you set a custom titlebar, GTK+ will do its best to convince the
    window manager not to put its own titlebar on the window.

If you would like specific GNOME applications (e.g. Evince) to behave
differently in order to integrate better into non-GNOME desktop
environments (e.g. reducing or avoiding API calls that result in CSDs),
I suggest you take that feature request upstream, taking their point of
view / design choices into account. Politeness makes sense even from a
purely selfish point of view: people tend to be uncooperative when you
insult their work.

One possibility would be to detect GNOME Shell (or some "we like CSDs"
GSetting that GNOME Shell could set), use CSD in Shell, and use WM
decorations / no title in the GtkHeaderBar on non-Shell, perhaps with
some convenience code in Gtk to centralize that logic:

     Shell
     /--------------------------\  <- CSD; app window starts here
     | [*] [&]  App     [=] [X] |  <- GtkHeaderBar with WM controls
     +--------------------------+
     |         hello            |
     |         world            |
     \--------------------------/

     other window manager
     /--------------------------\
     | [v]      App     [_|#|X] |  <- WM decorations
  ---+--------------------------+--- <- app window starts here
     | [*] [&]              [=] |  <- GtkHeaderBar without WM controls
     |--------------------------|
     |         hello            |
     |         world            |
     \--------------------------/

It seems unlikely that either Debian or upstream GNOME maintainers, who
are presumably happy with GNOME, are going to lead an effort to make
GNOME applications look less GNOME'y in non-GNOME environments; I'm
certainly not going to. So, it is likely that someone who advocates this
change will have to do the research, propose a solution/design that
makes sense and is implementable, and implement it. We've already seen
in this bug's discussion that attempts to patch in design changes via a
GtkModule are not sufficiently robust to be a good solution.

The fact that GNOME 3.14 adds the gtk-dialogs-use-header GSetting and
the gtk_application_prefers_app_menu() function (and hence GtkDialog no
longer uses CSD, and some apps' menu structures go back to being more
traditional, under non-GNOME) indicates that there is upstream interest
in this sort of thing.

I don't think the Debian GNOME maintainers are going to be willing to be
responsible for significant divergence from upstream Gtk, so, "upstream
first" seems the most sensible approach.

    S