To left or not to left, GNOME

I’m just another user who loves GNOME and suffers the blessing of its developers.

I’ve had the close button in the left since it was set by default in Ubuntu 10.04 and I liked it, and the button stayed in the left until GNOME 3.8.

GNOME 3.10 introduced Client Side Decoration (CSD), ie, now the application can paint the window border and buttons. Quoting from the linked site above:

A disadvantage of CSD is the inconsistency that brings between Apps that support them (mostly GNOME Apps) and Apps that don’t (3rd party Apps, like Firefox). However this is mostly in theory, because in practice, you won’t really be bothered from it.

A new widget called GtkHeaderBar was added in the process, and it was decided that the GtkHeaderBar will forcibly put the close button in the right, and then bug 706708 was filled, of course.

A fix was commited a month after the bug was filled and it entered in GTK+ 3.10.3. Now I can set the placement of the close button again, so Iet’s create a ~/.config/gtk-3.0/gtk.css with the following content:

and see what happens.

Clocks

tlontl-gnome-clocksthis is gnome-clocks, honoring the setting.

Nautilus

tlontl-nautilusand this is nautilus, not honoring the setting. It turned out that it isn’t using a GtkHeaderBar after all. You can see in the source code that a separator an a close button are manually added to the end of the top bar.

Gnome Tweak Tool

tlontl-gnome-tweak-tooland this is gnome-tweak-tool, honoring the setting, only that it has two GtkHeaderBar. The one to the left is not displaying the close button.

Inconsistency they said?

5 thoughts on “To left or not to left, GNOME

  1. Dragnucs

    Pretty annoying. But solving this is not obvious.

    A theoretical solution that came to my mind is to group header bars under some parent group widget. It would be that parent widget that takes the property has close button and then it decides on wich oof its child it should display it. This may apply to other properties like title and subtitle.

    Reply
  2. John

    Yeah, I really don’t know how to fix this in gnome-tweak-tool.

    I could not match the mockups without having two headerbars, and this is one consequence.

    Suggestions for how to fix this are welcome.

    John (g-t-t developer)

    Reply
  3. Michael Catanzaro

    In 3.12 it’ll be possible to add maximize and minimize buttons as well (on either side).

    AFAIK nautilus is the only remaining app to fake its own header bar; it’s listed as TODO on the goal page: https://wiki.gnome.org/Initiatives/GnomeGoals/HeaderBars

    Reply
  4. mohaa

    First I had to migrate from openrc to systemd because “gnome3.8″ has systemd hard dependency. then overnight, upgrade to “gnome3.10″ and the mess so goes on. The ugliest thing I have ever seen is here and it’s gnome.  You may loose hours to figure out which shell extension to use for basic functionalities. All development is done for the sake of gliding windows. Now, thank you RedHat. We all do love your efforts to ruin Gnome, making it something not portable first and now something unusable even on GNU/Linux. I may suggest the gnome devs to make these huge title bars look even larger and pink for the next release. By then, more distributions would be considering leaving gnome to redhat and fedora. yay!

    Reply
  5. Masin

    Hi,

    great article. I tried following your steps regarding gtk.css in Gnome 3.12, but to no avail. Is there something I have to consider to put it into effect?

    Cheers, Masin

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">