Thoughts on the Linux Mint X-Apps forks

You may be aware that Linux Mint has forked several GNOME applications, either directly from GNOME (Totem -> Xplayer, Evince -> Xreader, Eye of GNOME -> Xviewer), or indirectly via MATE (gedit -> pluma -> XEd).

GNOME is like the Debian of the Linux desktops. But is it a good thing? In the current state of the code, I don’t think so and I’ll explain why, with a solution: creating more shared libraries.

At the end of the day, it’s just a matter of design and usability concerns. We can safely say that the main reason behind the forks is that the Linux Mint developers don’t like the new design of GNOME applications with a GtkHeaderBar.

And there are perfectly valid reasons to not like headerbars. For gedit for example, see the list of usability regressions at this wiki page.

Currently the trend is GtkHeaderBar, but what will it be in 5 years, 10 years? Let’s face it, GNOME is here just following the new trend that came with smartphones and tablets.

So, a GNOME application developer needs to know that:

  • A GUI is an ever-changing thing, exactly like the clothes that you bought last year are already obsolete, right?
  • When the GUI changes too much, other developers don’t like it and fork the project. For valid reasons or not, this doesn’t matter.

The four X-Apps forks account for roughly 200k lines of code. In the short-term it works, Linux Mint has apps with a traditional UI. But hey, porting the code to GTK+ 4 will be another beast, because the four X-Apps still use the deprecated GtkUIManager and GtkAction APIs, among other things.

But when we look at the codebase, there are a lot of code that could be shared between a GNOME app and its fork(s). So there is a solution: creating more shared libraries. The shared libraries would contain the backend code, of course, but also some basic blocks for the UI. The application would just need to glue things up together, assembling objects, binding GObject properties to GSettings, create the main GtkWindow and a few other things.

The difference would be that instead of forking 200k lines of code, it would be forking maybe 20k lines, which is more manageable to maintain in the long term.

In the case of gedit, making its code more re-usable is exactly what I do since several years, but for another reason: being able to create easily specialized text editors or small IDEs.

Beside avoiding code duplication, creating a shared library has the nice side effect that it is much better documented (usually), and with an API browser like Devhelp, it’s a breeze to discover and understand a new codebase, it permits to have a nice overview of the classes. It’s of course possible to have such documentation for application code, but in practice few developers do that, although it would be a big step towards lowering the barrier to entry for newcomers.

When untangling some code from an application and putting it in a shared library, it is also easier to make the code unit testable (and unit tested!), or at least write a mini interactive test in case of frontend code. Making the code more stable, getting closer to bug-free code and thus more successful software.

Developing a shared library doesn’t necessarily mean to provide backward compatibility during 10 years. Nothing prevents you from bumping the major version of the library every 6 months if needed, making the new version parallel-installable with the previous major versions. So that applications are not forced to update the code when there is an API break.

But creating a library is more difficult, API design is hard. But in my opinion it is worth it. GNOME is not only a desktop environment with an application suite, it is also a development platform.

This entry was posted in gedit, gspell, GtkSourceView, Library development, Programming, Thoughts. Bookmark the permalink.

12 Responses to Thoughts on the Linux Mint X-Apps forks

  1. John McHugh says:

    The issue with tabs isn’t really a csd regression though is it. Gnome-Terminal suffers the same problem and they don’t use headerbar there. If a user opens gedit or gnome terminal and they open a tab then two tabs become visible to the user. If they close that tab or detach it then no tabs are visible to the user.
    So if they would like to reattach the tab they have detached like they do with web browsers they need to open redundant tabs on both windows in order to drag the detached tab back onto the original window and then close the redundant tab on the original window(Leaving the two tabs the user was working with in original window) and an extra redundant window for the user to close.
    If the tab bar were always visible then users could see the encoding and mimetype and they could attach and detach tabs without having to open and close redundant documents.

    • swilmet says:

      In gedit, the new tabs behavior came at the same time as the new design with the headerbar, in 3.12. But for the drag-n-drop, in gedit, you can drop a tab inside the main text area (the GtkSourceView widget, more precisely) and the tab will be added to the notebook. It’s maybe not possible with gnome-terminal.

      But the GTK+ developers and designers are working on a new tab bar widget. It’ll hopefully fix the usability issues (without introducing another set of regressions, I hope).

      Less on-topic, but to me GNOME 3 is still like a giant building site, still in beta after 5 years. Some features that I used in gnome-terminal have been removed (in the fork in Fedora at least), or at least have been removed from the menu: opening a new tab can be done only with a keyboard shortcut (Ctrl+Shift+T), moving a tab to its own window can be done only with drag-n-drop (which is not convenient when all my terminals are maximized. There was a menu entry for that in the right-click menu of the tab, but it has been removed).

      Without even talking about gnome-shell. With Wayland, when gnome-shell crashes, all the applications also crash. With GNOME 3.20 on Fedora, I have less crashes with gnome-shell, but one year ago I still had a lot of gnome-shell crashes. So, Wayland is an improvement in security, but the architecture built on top (in GNOME) is a huge regression in robustness.

      And to continue the rant, I don’t often use Nautilus (I’m more a terminal user), but I sorted my photos recently with Nautilus 3.20, and I was amazed by the number of bugs. Nautilus has also regressed in term of stability. I’ve reported a Nautilus bug maybe one year ago, but it was ignored.

      The same for gnome-software. Everybody seems to like gnome-software, but I have a lot of bugs with it. I reported some of the bugs, but they are still not fixed.

      But if you listen to some GNOME people, all is bright, everything is alright.

      • Andreas Tunek says:

        If you say you reported bugs it is always nice to provide links to the actual bugs.

      • lottin says:

        I agree. And not only Gnome, GTK has also become very unstable, which affects other desktop environments too. Every other week the theme I use breaks and needs to be fixed. I’m not talking about minor glitches but things like progress bars can no longer be seen at all. It’s a sad state of affairs. I think Linux on the desktop on the whole now is in considerably worse shape than it was 5 years ago.

      • peter says:

        What do you think is the root cause for the stability issues?

        BTW I don’t experience problems not as dramatically as you describe it.

        • swilmet says:

          The root cause is that writing software is hard. And writing desktop (interactive) software is harder than batch jobs like Unix commnands. There is a big difference between (1) writing a feature mostly bug-free, and (2) writing quickly a feature that seems to do the job, but in reality it’s full of bugs. It takes maybe the double of the time to write stable software, maybe more. Developers should take the time to write stable software, with a clean architecture and clean code. The priority should be to fix bugs, not writing new features in an already unstable software.

          I talked about this subject here:
          https://blogs.gnome.org/swilmet/2012/08/01/about-code-quality-and-maintainability/

  2. peter says:

    I meant: I don’t experience problems as dramatically as you described :-)

  3. Pingback: The Linux Mint 18.X is Leading to Greatness, not Fragmentation. – Michael Wilson

  4. Rojas says:

    Forks can happen when people are unsatisfied with the software and the developers take a petty attitude towards bug reports or are otherwise unwilling to address the issues. This is a situation that has plagued the GNOME project since 2011. You cannot blame Linux distributions for wanting to take corrective action. For example, if the latest Nautilus versions weren’t so shitty, Ubuntu would still package them instead of a locally-patched*, outdated version; Mint’s Nemo wouldn’t exist, etc.

    * With the patches added to restore back basic functionality taken away by upstream. (!) Isn’t it sad?

  5. Pingback: Linux Mint 18 improves security, but at a cost (TechRepublic) – sec.uno

Comments are closed.

Leave a Reply

Your email address will not be published.