IgnorantGuru's Blog

Linux software, news, and tips

Heads Up: GTK 3.20 Off To A Troubled Start

GTK 3.20 is entering distros, and it looks rough. If you use GNOME 3 or GTK3 applications, be advised that upgrading to 3.20 may cause extensive breakage. The new GTK 3.20 is hitting Arch Linux users with a number of upgrade problems. Arch is a rolling release distro that tends to get new versions of packages before most other distros, so new problems tend to be revealed there first. 3.20 hasn’t yet arrived in Debian Testing, but will likely be appearing soon. You may wish to choose your upgrade time and path carefully.

The GTK 3.20 release reportedly adds a new API for themes, which in the future may help reduce GTK3’s endless theme breakage problems. While this API change may be good news for users and theme developers in the future, in the short term it means almost all third-party themes will be seriously broken by the upgrade to GTK 3.20. (GTK3’s default theme is Adwaita, which usually avoids these problems.) All third-party themes will need to be updated or rewritten by the theme developers before they can be used very successfully with GTK 3.20. [Many applications also appear to need updates, as detailed in the update here.]

In addition, it appears our old friend Matthias Clasen has carelessly refactored the drag and drop code in GTK 3.20 (commits), causing DnD breakage and crashes in SpaceFM and Firefox, among others. Arch users have reported SpaceFM 1.0.5 crashing when using drag and drop in GTK 3.20 (even with Adwaita). In fact, this bug may cause the X server itself to crash or freeze, and there have been reports of other X-related issues with 3.20. Thus far I’ve been unable to reproduce that SpaceFM crash in tests on Archbang (which includes SpaceFM on its live ISO.) Further information is welcome on that crash report, but there are indications that the crash may be in GTK’s code itself, or perhaps due to the updated Adwaita. Other minor stderr warnings are also visible when running SpaceFM under GTK 3.20, although these should not cause a functional change.

As your upgrade to GTK 3.20 approaches, remember that SpaceFM may be built to run as a GTK2 or GTK3 application, and most distros provide a spacefm-gtk2 package. In fact, GTK2 is still SpaceFM’s default build (if you have those dev libs installed at build time). GTK2 tends to be much more stable through upgrades, which is handy in a file manager. The GTK3 version of SpaceFM does run well in general, but frequent theme and functional breakage may occur during upgrades to GTK3, which is NOT handy in a file manager.

Even if you normally prefer GTK3, you may want to consider holding back the upgrade to 3.20, or switch temporarily to a GTK2 build of SpaceFM, if you want to avoid GTK3’s growing pains for the next few weeks/months. Other applications may also be affected.

Overall, SpaceFM and my other projects are in a slow development phase, mostly just critical bugfixes being addressed recently. If you want a little adventure you can try SpaceFM alpha for some new features, including deep directory sizes and faster directory load.

UPDATE: Matthias Clasen has provided a more detailed explanation and documentation links for the changes in 3.20, makes excuses for breaking applications yet again, and asks application developers to give feedback.

April 20, 2016 - Posted by | News

12 Comments

  1. I’m hoping GTK doesn’t go insane just yet.

    I remember a while back you were pondering the idea of jumping ship and going with another toolkit. You’ve been my canary in the coal mines for this sort of thing. I jumped off the systemd ship (back to Slackware) because of a couple of your posts.

    Comment by spiralofhope | April 20, 2016

  2. Why don’t you rewrite SpaceFM graphical side in pure Xlib and get out of the GUI Toolkits madness?
    It would make both you and users less insane.

    Comment by Anonymous | April 22, 2016

    • Xlib is no good, because then it won’t work on Wayland.
      The best option would be OpenGL ES.
      Portable and without the madness of modern toolkits.

      Comment by Anonymous | April 23, 2016

      • OpenGL ES looks like more of a graphics API than a GUI? Although it may lead to the latter, I’ll keep an eye on that.

        From what I’ve seen and heard about, only GTK+ and Qt are suitable for an application like SpaceFM, which has internationalization. Otherwise it’s hard to support other languages and get other fairly modern GUI features such as themes. I think the desktop toolkit selection is also suffering from the movement to tablets and phones, etc.

        For SpaceFM, GTK3 has been a somewhat time-consuming annoyance with little gain imo, and hard to say where it’s going, but I like that we retained the GTK2 support so that can act as a fallback, and thus far maintainance has been within a doable range. For my personal use, I stick to GTK2 now because I don’t like where they’ve taken GTK3’s UI, and it tends to break with upgrades. I’d say GTK3’s biggest problem is its dev culture, which has alienated many developers and users. Qt tends to be more focused, but also comes from the corporate Linux culture that does not welcome genuine community involvement or innovation, and tends toward bloat and uncreative overcomplexity. I consider both of these toolkits a questionable investment mostly due to their dev cultures, although I think of the two, Qt is the saner choice these days (and you can still use glib, although that gets you involved with that same dev culture somewhat).

        SpaceFM being a prototype which has already stretched the original codebase a bit too much, I think if I ever did convert SpaceFM to another GUI toolkit, I would do a rewrite which highly encapsulates the GUI elements, and perhaps build in an IDE, such that it could use one of several underlying toolkits. There are already toolkits that do this, based on GTK, Qt, etc., but making my own would be interesting because I could take some of the design mode concepts further, sort of allowing the user to build/extend an application by using it. Some asynchronous I/O could improve it too, etc.

        No shortage of ideas there (including from users, whose feedback on earlier projects inspired SpaceFM in the first place), but SpaceFM is actually a large project when you get into the code, and a rewrite is quite a lot of work. Could accomplish some neat things though, just takes a major commitment and focus over several years.

        In my view, Linux (and general) user and dev culture tends to be focused a little too much on appearances. There are certainly users who get into innovative underlying functionality, yet there is a large focus on how the GUI looks, minor aspects of its behavior, etc. We all get drawn into this somewhat in the desire to have a UI that looks and works ‘good’ (which is highly subjective). Certainly the UI is important, but I encourage users to get into the creative aspects of applications and systems, particularly in SpaceFM. Learning to add your own custom commands to SpaceFM, doing a little light scripting, and using SpaceFM Dialog to create mini-apps and automate/extend the application offers an almost endless area of creative potential, which I think is more rewarding than fretting over minor UI differences. SpaceFM is very much like a ‘Lego’ kit where you can build what you want.

        When is a UI and IDE-like environment ‘good enough’, so that you can move on with the focus of applying it in innovative and custom ways, without having to change and stabilize your working environment every other day? I think the ‘bigger, better, more’ mentality could be profitably replaced with a respect for the concept of ‘good enough’ and ‘knowing when to stop’, making some decent, stable, secure tools for ourselves and using them. But of course in corporate profit-driven models, bigger-better-more reigns supreme, which mostly creates chaos and poor quality.

        Comment by IgnorantGuru | April 23, 2016

        • It’s the old question of using existing GUI Toolkits (GTK, Qt) or going barebones and creating your own customized interface from lower level tools like Xlib, OpenGL.

          About keeping things simple, you should look into the suckless philosophy in case you don’t know it already. http://suckless.org/philosophy I think they share that idea.

          Keep up the good work.
          KISS.

          Comment by Anonymous | April 23, 2016

        • I like that you mentioned the extensibility of SpaceFM. There are a fair number of other programs out there that use a similar ideology; and the truth is that it just plain works. It attracts people who are already power users, or users that don’t mind learning a bit to accomplish what they want done.

          As a personal example, I got tired of resizing the panes in SpaceFM and created a quick script that hooks into its socket to equalize the pane sizes. Hook it into SpaceFM with a custom command and keybinding and BAM, I get a new SpaceFM feature for free.

          I think that is a direct result of what you’re talking about with “knowing when to stop”. I’m finally building a game library manager tool, and I’ve considered omitting a feature or two simply because it could end up too bloated for little gain. If abstractions pile on top of each other too much in a project, you end up with something like GNOME 3’s file manager that — in its quest to get even the unsavvy to use it — falls completely flat for any serious file management.

          Vim is a famous example. It packs in a ton of features that you might not even realize you need. And in the event that Vim’s not good enough, you can write your own plugins. Software that provides a good core function and invites users to build upon it tends to enjoy a more active, more loyal, vibrant community.

          As an aside, I hope GCC 5.3 hasn’t been too terrible for udevil and SpaceFM. It’s apparently caused some headaches for some other upstreams on Gentoo.

          Comment by sporkbox | May 1, 2016

  3. Hi.
    I created a custom widget library for GTK+ 2.x before.
    I think i would be happy if you use and comment about it, though hard to apply feedbacks quickly as my decision is so slow :-)

    https://github.com/whitestone8214/gtkwidget2

    Comment by - | April 29, 2016

  4. UPDATE: Matthias Clasen has provided a more detailed explanation and documentation links for the changes in 3.20, and asks application developers to give feedback. Also a Reddit discussion of this.

    Comment by IgnorantGuru | April 30, 2016

  5. Maybe this could help with the GUI?

    https://github.com/vurtun/nuklear

    Comment by ancow | May 25, 2016

  6. FYI: breakage introduced by gtk3.20 has caused the author of RoxTerm to throw in the towel
    https://sourceforge.net/p/roxterm/discussion/422638/thread/60da6975/

    Comment by stewie | May 27, 2016

    • Sorry to hear that. He should never have fully committed to GTK3. As I keep telling people, migrate the code to GTK3 while retaining GTK2 support, it’s not usually that extreme to do. I for one would appreciate a continuing GTK2 fork of Roxterm.

      The Roxterm bug #125 that was created by GTK 3.20.

      This is a prime example of how GTK’s dev practices undermine application devs. They are simply destroying GTK, with no thought to existing applications, backward compatibility, etc.

      Comment by IgnorantGuru | May 27, 2016

  7. News and feedback on GTK 4 and 5 – looks like the terrible dev patterns will continue and worsen.

    Comment by IgnorantGuru | July 5, 2016


Sorry, the comment form is closed at this time.