After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 779416 - Configurable title bar presence
Configurable title bar presence
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-03-01 12:26 UTC by Hugo Osvaldo Barrera
Modified: 2017-12-08 02:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Hugo Osvaldo Barrera 2017-03-01 12:26:38 UTC
I'm moving from Xorg to Wayland, but came across the problema that apps always draw a title bar, since the WM no longer controls this, but rather, individual apps do.

When commenting the issue with the WM developers, they mentioned that the only workaround is to use a patched GTK, since GTK does not allow users to configure this. Of course, this isn't very nice for end-users (keeping updated a patched GTK is a good way to break one's system).

It makes complete sense for GTK to have a configuration option to disable title bars globally (eg: allow changing the default to "off").

Note that I'm not asking to disable them by default, just to make this configurable.

I know applications CAN have a setting to disable them, but contacting every single application developer out there, and convincing them of adding such a setting (some apps don't even have a settings screen!) is no feasible (it also means that users have to configure the same thing dozens of times).

TBH, currently, this is the only thing that's blocking Xorg->Wayland migration.
Comment 1 Matthias Clasen 2017-03-01 12:29:31 UTC
> It makes complete sense for GTK to have a configuration option to disable title 
> bars globally (eg: allow changing the default to "off").

No, it doesn't
Comment 2 Matthias Clasen 2017-03-01 12:38:57 UTC
That being said, there's already ways to influence this for the platform, via the gtk-dialogs-show-header setting.
Comment 3 Eugen Klim 2017-03-01 13:21:56 UTC
>No, it doesn't

Yes, it does. If on wayland empty header bars are drawn on client side so there shoul be a way to turn them off for all gtk apps. Even qt has a QT_WAYLAND_DISABLE_WINDOWDECORATION variable.

>gtk-dialogs-show-header

It does not disable header bars for apps.
Comment 4 Matthias Clasen 2017-03-01 16:53:15 UTC
(In reply to Eugen Klim from comment #3)
 
> >gtk-dialogs-show-header
> 
> It does not disable header bars for apps.

No, and we won't have a setting that 'disables' header bars that an application has explicitly added.
Comment 5 Hugo Osvaldo Barrera 2017-03-01 17:01:12 UTC
> No, and we won't have a setting that 'disables' header bars that an application has explicitly added.

Most applications don't add it explicitly, but rather implicitly (since it's the default).

On Xorg, windows managers could hide bars when they made no sense. It's sensible to keep the same functionality for wayland.

> No, it doesn't

Why not? I don't see any drawbacks, and titlebars are useless in many scenarios (like, for example, on tiling window managers).
Comment 6 Emmanuele Bassi (:ebassi) 2017-03-01 17:05:30 UTC
It seems we're going in circles.

If the header bar is automatically added by GTK+ — i.e. for dialogs, or for top-level windows under Wayland — we are amenable to have a platform setting to toggle that; GtkDialog already has one, so that would leave adding a setting for GtkWindow.

What we are *not* going to do is to have a toggle that disables GtkHeaderBar widgets added by the application, because that would *break* applications that put the header bar widget there for a reason.
Comment 7 Hugo Osvaldo Barrera 2017-03-01 17:42:58 UTC
> If the header bar is automatically added by GTK+ — i.e. for dialogs, or for top-level windows under Wayland — we are amenable to have a platform setting to toggle that; GtkDialog already has one, so that would leave adding a setting for GtkWindow.

Right, that sounds perfect (not entirely sure what non-top level windows would be though). A system-wide or user-wide setting (such as `.config/gtk-3.0/settings.ini`), or an an env var would do (don't really care which of these it is).

> What we are *not* going to do is to have a toggle that disables GtkHeaderBar widgets added by the application, because that would *break* applications that put the header bar widget there for a reason.

Yes, I agree completely. If an application explicitly adds it, then it should be visible anyway. (I don't think I use any such applications anyway).
Comment 8 Daniel Stone 2017-03-01 18:38:26 UTC
(In reply to Hugo Osvaldo Barrera from comment #5)
> Why not? I don't see any drawbacks, and titlebars are useless in many
> scenarios (like, for example, on tiling window managers).

There's more to making tiling work properly than just disabling title bars, and that's something which we'll work on separately for Wayland.
Comment 9 Eugen Klim 2017-03-02 08:09:55 UTC
>What we are *not* going to do is to have a toggle that disables GtkHeaderBar

Well, the problem does not concern title bar with widgets, but it is vital to have possibility of turning off useless title bars with just a label and a close button.
Comment 10 Hugo Osvaldo Barrera 2017-03-26 04:08:46 UTC
"gtk-dialogs-show-header" doesn't seem to work either though:

    Gtk-WARNING **: Unknown key gtk-dialogs-show-header in /home/hugo/.config/gtk-3.0/settings.ini

I get this on any app that uses gtk 3 (3.22.10).
Comment 11 Hugo Osvaldo Barrera 2017-04-29 14:14:32 UTC
I believe that the patch provided here somewhat suppresses the need for this feature (or rather, provides an alternative implementation which is good enough for me).

https://bugzilla.gnome.org/show_bug.cgi?id=781909