Posted on by Olav Vitters

Perfect storm: GTK+3.x behaviour under KDE and Firefox’s move to GTK+3.x

Introduction

At Mageia, various people suddenly started complaining about the scrollbar behaviour of GTK+3.x. Not always in the most constructive manner. One example:

“GTK+3 is the way of the future and all you luddites had better fall in line sooner if not later”

The reason was two fold. For one, Mageia could not use oxygen-gtk anymore. Oxygen-gtk played an important part in ensuring GTK+ not only looked but also behaved like Qt. The second big reason was the Firefox package being compiled with GTK+3.x support instead of GTK+2.x.

Loads of people use Firefox. These people don’t like their Firefox behaving different from what they’re used to and expect.

Already lots of moons ago people complained about the different behaviour of toolkits. One of the solutions is xsettings; a way to inform a toolkit at runtime regarding about settings such as (quoting): “double click timeout, drag-and-drop threshold, and default foreground and background colors for all applications running within a desktop”. Checking the xsettings spec git log this standard was created around 2001!

The solution seems obvious: Ensure the right xsetting is set. In practice there were some difficulties:

  1. The KDE xsettings manager was unmaintained for ~3 years
  2. There wasn’t any xsetting for this in gtk+
  3. GNOME bug 688524: Expose gtk-primary-button-warps-slider as an X setting was marked as WONTFIX

Road towards fixing the behaviour

First up was getting commit access to xsettings-kde. This was initially written by various Mageia people using the example code included in the xsettings spec. Unfortunately it seems the maintenance more or less died as soon as it was moved to KDE. One of the listed maintainers is Colin Guthrie; the same Mageia person whom I always pester for getting fixes for things I don’t understand. Furthermore, I recently helped out Ben Cooksley (KDE sysadmin) by fixing a GNOME mailserver misconfiguration which caused problems for KDE. Surely us finally (configuration was there for years) not causing problems for KDE anymore was worth KDE commit access right?
A few days after requesting access it was the same Ben Cooksley who setup the account! Though probably not a good idea to follow the same path if you want KDE commit access. 😛

Next up: the gtk+ xsetting. At the time of requesting xsettings-kde access, I didn’t know that gtk+ lacked the xsetting to control the scrollbar behaviour. Reading the related bug it was pretty clear the WONTFIX was not so much about the xsetting itself: The bug wanted an xsetting which was controlled by gsettings. Having an xsetting in gsettings is pretty much over the top. We already have an ini file (applies to everything), xsetting manager/client, xsetting overrides key in gnome-settings-daemon, etc. A gsetting changing an xsetting? This resulted in the WONTFIX. Matthias Clasen was worried if KDE would actually use the xsetting. Quite nice to explain that I got KDE commit access specifically to improve xsettings-kde (+ok from Colin Guthrie). This resulted in an “ok to reopen”. The xsettings patch was outdated plus I didn’t like the chosen xsettings name, so I spend 5 minutes writing a new one. Most of those 5 minutes I spent on aligning my commit message with previous ones as well as figuring out the nicest place to put the one liner change.

Lastly: Patching it back into the existing Mageia packages. I then discovered I made a typo in the xsettings-kde patch. Ugh.

Response from users

<R> is the firefox misbehaviour under gtk3 on cauldron fixed now?
<M> yes, the scrollbar works fine, now

Also seems quite telling people are trying this out within 1 hour of me updating the packages!

The patches

For any distribution wanting these fixes as well. The easily backportable patches:

I’m going to send above information to the GNOME distributor mailing list with the request to forward it. Any GNOME packager should subscribe themselves to this mailing list!

Other desktops

Other desktop environments should determine for themselves if they want to change GTK+ behaviour. Any Qt using distribution should make use of xsettings-kde. If a desktop environment (e.g. MATE) is maintaining a gnome-settings-daemon fork, one way would be to change the ‘fixed_entries’ variable in plugins/xsettings/gsd-xsettings-manager.c. If the desktop uses a custom GTK+ theme, another solution would be to store a settings.ini in the theme directory next to the gtk.css file. I’ve suggested to the Mageia MATE packager to reach out to MATE.

Future

Various other xsettings which might make sense to set under KDE. There’s some backlog in the xsettings-kde maintenance which needs to be done. For the backlog I probably need to find some assistance (I’m not a C developer). I need to check if there are outstanding bugs and where they are.

My intention is that GTK+ under other desktop environments at most is considered different. GTK+ should not be out of place (or worse).

7 Replies to “Perfect storm: GTK+3.x behaviour under KDE and Firefox’s move to GTK+3.x”

  1. I’m going to go out on a limb and guess xsettings is not supported under Wayland, which is probably where some of the resistance is coming from.

    1. For Mageia, not that much at the moment. None of the other desktop environments (under Mageia) have been setup to let people easily try Wayland.

      I need to ask what the idea is with Wayland. I’m guessing at the moment it isn’t possible for gtk+ to provide something like xsettings under Wayland. From what I understood this affects a multiple of things. This as xsettings also ensures the double click speed and so on.

      I’m planning to ask that during FOSDEM. If people want to assist/fix, feel free. As said in the blog, I’m not a C developer. Still, just two one liner fixes made quite a big difference. IMO Wayland has loads of small issues still left.

Comments are closed.