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

[Vlad Orlov]

Hi,

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

Yes, the subject of this bug report isn't correct anymore. But as I said in my
previous letter (to Tsu Jan), the inability to resize any windows that _have_
CSD is still present in 3.14. Since this is basically the same issue that has
been reported originally, I think this bug should be kept open. Just the title
needs to be changed.


> 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

Yes, that's what I'm thinking about. GTK+ 3.14 already has the logic that
enables or disables CSD in dialog windows, depending on the current
environment. Similar logic might be used to use either WM decorations
or CSD. That would solve this bug for good (you would be able to resize
the windows normally with a mouse).


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

Yes, our experiments so far led to two results, both not acceptable as a
good solution yet:

- the headerbar is removed completely, taking any app-specific buttons
  with it, making the app completely or partially unusable. The only control
  that's not removed is the "fallback" app menu which is converted to the
  "classic" menu. Not a good solution.

- the headerbar is not removed, therefore some apps have duplicated
  window title (in WM decorations and in the headerbar). This doesn't
  break the functionality but doesn't _look_ good either.

Since at least one headerbar item (the app menu) can be converted to
the conventional menu, I was hoping to find a way to do the same for
the other headerbar buttons (excluding WM controls of course) and
therefore get rid of the headerbar in the end.

Of course, this would be also paired with the aforementioned logic
(leave the headerbars alone in Gnome Shell, convert them in other
environments). That would not only solve this bug with window resizing,
but also make Gnome apps look less out-of-place in the environments
other than Gnome Shell.


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

Oh, that's interesting, I didn't know about gtk_application_prefers_app_menu().
In regard to what had been said above, it would certainly be nice to have some
kind of gtk_application_prefers_headerbar() function as well. :)


As for now, I don't know whether someone comes up with a reasonable solution,
but I'm already afraid we might run out of time due to the coming freeze of Jessie.