New to Linux and the open source world? We have compiled a huge list of resources to help you go through Linux and its distributions. Visit the full Linux guide page right now.

.

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

For the price of one cup of coffee per month:

  • Support the FOSS Post to produce more content.
  • Get a special account on our website.
  • Remove all the ads you are seeing (including this one!).
  • Help us get to our goal of 100 supporters, to start many initiatives.


.
21 Comment
Anass Ahmed July 22, 2016
|
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).
disqus_v3PmObl5gf July 24, 2016
|
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).
Muhammad Saied July 25, 2016
|
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?
Rockiger July 30, 2016
|
Forking is evil! Work together, not against each other!
Jake Times February 11, 2018
|
Yes completely agree forking might be the way to go Or maybe even create a new UI toolkit from scratch. With a big team its possible I have actually been tempted to create a new UI toolkit and have been playing around with cairo graphics recently I believe for application developers it is necessary because GTK isnt even that easy to use plus stability is very very important. When it comes to UI toolkits it isnt a major issue how many there are, it wont make life harder for others
the gtk guy September 22, 2018
|
I have used Gtk from 3.6 to 3.22 and never had a problem. I don't try all kinds of weird themes either, so that probably helped. I look at it this way: You can use Gtk and have nice Pythonic code, or use Qt and have Python wrapped C++. Gtk actively weeds out old deprecated code and marks the 'new' way, which for some reason makes some devs hopping mad. Or you can go with Qt, which leaves all outdated code there for backward compatibility, which tends to be confusing. Any way you slice it, there is a drawback to whatever GUI toolkit you use. Each to his own.
Daiquiri December 12, 2018
|
QT is superior in every domain, so why this need to develop on GTK?
syslog March 28, 2020
|
i agree, gtk is a shame... the moron leading the GTK+ development spoil the all linux community, Because curently gtk is a main part of linux desktops. Even for people using kde, apps with gtk ui are sometimes necessary.