About GTK+

GTK+ is a graphical user interface toolkit that is used to build applications, developers can use GTK+ to create applications’ interfaces to provide the ease of use to end users. GTK+ is developed by the GNU team which is also leading the development for many other components of the GNOME project since 1999.

GTK+ 1.0 was released in 1998, GTK+ 2 was released in 2002 and GTK+ 3 was introduced in 2011. You can see the long time between the release of version 2 and version 3, we needed such an update to the whole library to keep up with the updates and changes in the programming industry. GTK+ 2 was nice actually, well it was old and buggy a lot but still, the themes that you used to find on the Internet for GTK+ used to work for years, the applications built against version 2 never crashed because a comparability issue with the main +GTK library.

The new days with GTK+ 3

gtk logo


Now there’s a problem when it comes to GTK+ 3, the development team is like “committed” to destroy the API and ABI compatibility completely for most versions every two or three versions of it. For example: if you have a GTK+ theme that works with GTK+ 3.18, it will not work with you on GTK+ 3.20, If you developed your application by using the GTK+ 3.14 library for example, it may suddenly stop working in GTK+ 3.16 because the developers removed or updated some API bindings that cause your problem functionality to stop working. This is causing a lot of problems for third-party developers on the Linux desktop.

For me, as a Python developer who loves to build his applications using the GTK+ library, this is hell, you will need to check and update the API bindings (PyGObject in my case) almost every 6 months or maybe even less to remove the old bindings from your program and replace them with the new ones that you find from the release notes for GTK+.

If you are a normal user, most likely you will notice that your themes that you downloaded and installed before on your desktop suddenly stopped working perfectly, you’ll have to Google for another one. Some applications that you may use in daily basis may crash because of using an older version of the API and then you will have to face a lot of troubles.

Same thing is happening with a lot of people actually, for example:

  • Vivacious theme: A Nice GTK+ theme for the Linux desktop doesn’t work on GTK+ 3.20, it only works on 3.16 and 3.18 (which was released a few months before 3.20 actually), the reason as the developer states is:

It does not support GTK 3.20 yet. (Arch, Fedora 24) To do that we have to re-write everything!… GTK 3.20 is that different! thats hours, days, weeks of work. We are working on it but please understand it’s not simple. It’s hours and days of our free time.

  • Caja: The file manager for the MATE desktop is crashing because of the API incompatibility, they are searching for a workaround for this.
  • And many else you may find after Googleing, if you are a developer you may have already faced it.

Are the developers working to fix it? Nope, Actually they will break it more

Have a look to this post of on of GTK+ developers about the hackfest they made for the future of GTK+, they will break the API and ABI compatibility every 6 months, this means that the GTK+ themes developers and all 3rd-party applications developers will need to check their applications code every 6 months and replace it, and this is quit interesting level of madness actually that we need to spot here.

Can you imagine thousands of free-time side-committed developers of free and open-source software, having (all of them) to update their applications and release it again every 6 months? Or maybe 2 years at most as GTK+ developers wish in the future after GTK 3.26?

This is going to break a lot of applications for desktop users and will cause a lot of headache for third-party developers and even for other Linux desktops like MATE, Xfce and Cinnamon.. etc. And the GTK+ development team doesn’t really seem to care much about it. They just care for their GNOME desktop and nothing else outside it.

Many 3rd-party developers are working in their free time, not as a full-time staff. Do you think that they will all re-create their applications because of the folks at GTK+ breaking the API on their minds every 6 months?

This means a lot of problems for you – as an end user – because it means that Linux desktop users will face a hard time in the coming months after the applications they used to work before suddenly crash. What will you do then?

Now we are not requiring GTK+ 2 applications to work on version 3, nor we are asking the same for version 3 andversion 4, but why not for GTK+ 3.18 and GTK+ 3.20? Look to Qt library development, all applications of the 4.x version for example are working on the whole series for Qt 4.x, applications developers don’t need to re-write the whole interface because of an update between 4.2 and 4.4.

Is it that hard to just not break the things up?

The Solution? As we used to do it: Forking

GTK+ developers said it clearly then; the development speed will increase and more things will break even for GTK+ 5, they are committed to break the things up at every new version until they reach something like 4.6 and then, they will keep breaking it, but the point is, it will be for after a little more time (2 years).

We think that it’s time to fork the GTK+ library, creating something new that keeps updating and adding new features with keeping the old API and ABI compatibility for at least 3 or 4 years in order to combine both rapid-development and API-compatibility together. GTK+ developers are more like of Frodo of the “Lord of The Rings” carrying the future of all of us, as a small hobbit.

It’s not acceptable that a lonely development team decide the whole future for the Linux desktop, breaking whole work of thousands of developers because a decision of some developers at a hackfest. Even their plan for long compatibility will not work perfectly because many Linux distributions will not ship the same version of the library, thus, you may find an application working on Ubuntu but not Arch in the future.

Linux Mint team forked some of the default applications for GNOME under the name “X-Apps”, they want to make it more compatible with MATE and Cinnamon instead of just GNOME Shell and to make development of their operating system under their hands.

Forking GTK+ library is hard because it’s really a big project, but it may be very necessary if things are not changed.

What’s your thoughts about this manner? Let’s hear them.

Facebook Comments

Today's Top Picks for Our Readers:
Recommended by Recommended by NetLine

M.Hanny Sabbagh

CS student. Living in Istanbul. Python programmer and open source software enthusiast. Worked on developing a lot of free software. The founder of FOSS Post.

Load More Related Articles
  • Anass Ahmed

    They said that the Theme API 3.20 is going to be stable (it was a huge update to switch from classes to dependent node tags for elements). I’m optimistic on that side.

    The library API for apps is a bit complicated, and I feel that pressure when I develop something that’s supposed to integrate with others work, and should be foundation for other apps. This is mainly a matter of design that should bear backward-compatibility in mind.

    I don’t think that the solution is to fork, but maybe trying to join forces (Cinnamon, MATE, Elementry, and Unity) with GTK+ team (GNOME team mainly) to have a mutual and unified design decision that doesn’t hurt anyone of them.

    Another solution for the end user is to use the new sandboxed apps (Snaps, Flatpaks, or AppImages) to have the required version of GTK+ bundled with the app (in case of Flatpak, it’ll depend on a Platfrom SDK).

    • Hello Anass.

      Well it took them a long time since the release of version 3.x to make it stable, after around 1 year maybe they will start working on 4.x branch (it will start from 3.27) and I believe the theme API will also change at that time, the problem is very huge because of this, hundreds of themes and developers efforts have been sent to trash because of such decisions.

      I don’t think that such join can happen; MATE is working on their own and already facing bugs that can’t be solved upstream because of GNOME Shell, and Mint (Cinnamon) has just forked many GNOME applications under the name “X-apps”, I guess a fork is a better available option for all of us, they will have their own rapid insane GTK+ library and we will have our own stable one.

      I will check sand-boxed applications, the idea seems good but both security and the package size are the hard-pain here, putting all libraries into each application means a very big size for users with slow internet connection.

      • Anass Ahmed

        The 2 issues you mentioned about sanboxed apps are on their way to be fixed:
        1. The app size, will be decreased (in Flatpak at least) because of sharing common libraries (Platform SDKs).
        2. The security concerns should be covered with Wayland/Mir implementations and Portal interfaces. (Android-like permission system)

        I don’t like fragmentation, especially in main and big libraries/components like GTK+ and Qt. It’s bad for all. There should be a committee from different desktop developers to control the future of this library based on mutual interests.

        • Daniel Espinosa

          I agree Anass, fork is good if it is time, but may not it is not now.

          I think we need a good plan for make stable things *starting now*. This is, GTK+ as some plans shown, is to make it stable in a year, hope their plan really make less changes on API / behavior side, release a 4.0 for it and start 5.0 branch to continue breaking things.

          4.0 should be released as soon as possible.

  • disqus_v3PmObl5gf

    Luckily there are other toolkits than GTK+, so to claim that messing up GTK+ will “destroy the linux desktop” is simply ridiculous. Having said that, breaking backward compatibility in well-established projects without a good reason *will* lead to serious trouble (just ask the python 3 guys what it’s like). In the worst case GTK+ will only end up destroying itself (and most likely not everyone necessarily would consider that a complete disaster…).

    Sure go ahead and fork GTK+, but don’t underestimate the amount of work and continued dedication it takes to keep such fork alive (just ask the http://pyjs.org/ guys about how they basically destroyed the pyjamas project). On the other hand, when done right, and with support of a significant part of the community, it might lead the project in a new and refreshing direction (as proved by the xorg and libreoffice guys).

    • Bro, GTK+ is like the main ui toolkit on the Linux desktop, CInnamon, MATE, Xfce, GNOME Shell, Unity, LXDE.. they all use it, so if it is going to break things, it truly means that it is breaking the LInux desktop, interfaces developers will have troubles in every new version to tweak their code, and normal applications developers (Like almost all your daily applications) are using GTK+, this code is very important piece.

      Yes I know the costs of forking GTK+ and they are high for sure, that’s why nobody did it yet but I am sure someone will if things go bad, we hope to see a good fork running soon.

      • disqus_v3PmObl5gf

        Long live KDE 😉

  • Muhammad Saied

    Yeah, just like libav forked ffmpeg maybe? forking is going to make the user life even harder, how are you going to install apps that use the original GTK+ along with the ones which use the forked one? is the fork going to use another name? why not rewrite the apps to use Qt instead of rewriting them to use the fork?

    • It depends on how you fork it; Cinnamon is a fork of Gnome Shell, MATE is a fork of Gnome 2.x, and they are all working and amazing, libav team forked ffmpeg for non-sense reasons and now Debian is going back for ffmpeg by itself.

      All of this can be done via the package manager or as a snaps, there are a lot of options, they can be installed together and then imported just like the normal GTK library for example.

  • Forking is evil! Work together, not against each other!

    • Well.. You can say that to GNOME developers I guess, two points of views can’t be mixed together in a single code, they have already broke a lot of things in GNOME 3 and now they are breaking people’ work by GTK+, how isn’t that evil too..?

      • As I understand it, you have LTS versions of GTK. These are stable for 2 years. I don’t think this is too bad. Dividing a crucial FOSS project would be much worse, imo.

        This is imo the biggest problem of oss: Having the same goal, but dividing forces about minor differences. Look at all the shit canonical is doing by themselves, Stallman always bad mouthing other projects. The list goes on and on.

        • No, there are no such versions yet, it’s all on the plans-list.

          Well in business no one will buy from you if you are not the vendor of everything you sell, Redhat doesn’t have a problem since it’s contribution to the OSS is almost everywhere, which is why Canonical forks everything (Mir for example, a bad fork no one will use else than Ubuntu, Wayland is the boss here).

          But it’s also not acceptable that a group of 100 or 200 people control the whole desktop of Linux (Literally, GTK+ is in the core more than many people think) so I don’t know if a company like Canonical likes that, or even the normal users or developers.

          • 4 month later, I have to admit, I see things differently.

            While I am still not a fan of forking (who would commit to maintain gtk?), I am keen to abandon gtk all together and switch to qt.

            qt is miles ahead of gtk. Development speed, quality, backward copatibility – almost everything is better. Right now the only disadvantage of qt would be language bindings. Beside C++ you only have Python for qt5. Hopefully this will change, especially js could be a good platform.