Challange your knowledege, and take a quiz.Go to FOSS Quiz
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
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?
Browse FOSS Post ad-free when you subscribe to PatreonBuy Some Coffee
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.