10 Years Later

10 years ago, in 2009, when I was 19 years old, during the summer after my second year at the university, I started to develop a new Free/Libre desktop application for GNU/Linux for writing LaTeX documents, now called GNOME LaTeX, based on the GTK GUI toolkit.1)

I quickly realized that the plumbing for developing such an application was lacking. It required to re-invent the wheel, basically re-implementing the core of gedit (50k lines of code back then, without counting the plugins, to have a top-notch implementation). There was the GtkSourceView library – used by gedit – but it was far from sufficient. What I did for GNOME LaTeX is to have a much simpler implementation than the gedit core, leaving out some features and have a lower quality for the essential features.2)

That’s why 2-3 years later I got involved to improve GtkSourceView, and to kickstart a project to make the gedit source code more re-usable.

A decade later, all my GNOME projects

The result, including some side projects:

  • I’ve improved a lot GtkSourceView, receiving very good feedback from application developers.
  • I’ve created 3 other libraries: gspell, Tepl and Amtk.
  • I’ve created in total 3 GTK text editors: GNOME LaTeX, gCSVedit and Gnotepad.
  • I’ve contributed extensively to gedit, Devhelp and its libdevhelp.
  • I’ve contributed a little to GLib and GTK, including the addition of some small APIs.
  • I’ve started to write the book The GLib/GTK Development Platform – A Getting Started Guide, for the C language (70 pages currently).
  • And other yak shaving and side projects: gnome-c-utils, a brochure on GLib/GTK for the FOSDEM conference, and of course some contributions to other GNOME modules.
  • Andthen:
    • Error: not enough funding.
    • Too much stress, I needed to rest.

The gedit codebase has shrunk, but not as much as I would like. It stems from the fact that the gedit core provides an API for plugins, so either the API must remain intact, or when breaking the API the official plugins need to be adapted, and lots of third-party plugins would be unavailable during possibly a long time. So it complicates matter significantly when wanting to do big refactorings in the gedit core.

Statistics

Just counting my GNOME or GNOME-related projects:

  • 6200 Git commits.
  • Author of ~140k lines of code, according to git blame in *.{c,h,vala,py} files (the vast majority being C library code).
  • Contributions in more than 30 GNOME Git repositories.
  • Some modules that I maintained or created are installed on millions of computers worldwide, thanks to being installed by default with GNOME.

A vision – Developing software product lines for GNOME

In short, my focus in GNOME is to make more code re-usable, especially in the field of text editors and other developer tools. The code is written as a set of object-oriented libraries. At most flexible at best.

It’s very similar to the “as a library” philosophy of the LLVM compiler infrastructure project:

“A corpus of functionality built as a set of libraries that can be sliced and remixed in different ways per the needs of different use-cases.” (Chris Lattner, original co-author of LLVM)

And it enables new possibilities: create software product lines! Instead of developing one application like gedit, the idea is to be able to develop a set of similar applications, each specialized for a different use-case. GNOME LaTeX is specialized for writing LaTeX documents, gCSVedit is specialized for CSV/TSV files, etc. There is still a need for a general-purpose text editor like gedit or Gnotepad, when a specialized text editor has not yet been developed.

A specialized application – by definition – has the potential to be better at its targeted task. Ideally, the application Just Works out-of-the-box, without the need to spend a lot of time to configure the application, finding plugins, etc.

This vision can be applied to many situations:

  • For text editors as previously explained.
  • I’ve almost finished to implement it for the Devhelp API browser, to be able to create specialized API browsers for specific development platforms.
  • For other desktop environments that prefer a traditional GUI instead of the more modern GNOME GUI for applications: from the same codebase (a library), create two applications, one with the old GUI and the other with the new GUI. This would permit to avoid forking the code or writing new applications from scratch.
  • For the desktop itself: create a software product line to be able to develop easily new desktops like gnome-shell.

Writing almost all the code as re-usable code is harder, but it is always possible: it is just software after all. And a well-designed library has a cleaner codebase and is easier to understand thanks to its API documentation.

Revisions

  • 2019-08-23: Add section about the vision with software product lines and specialized applications. Remove less important paragraphs to not make the article too long.
  • 2019-08-25: Add more details and a second footnote to the introduction.

Footnotes   [ + ]

1. The idea to develop a desktop application – instead of some other kind of software – didn’t come out of thin air. In primary and secondary school I did web development, but I no longer wanted to play in that field. During the second year at the university, we needed to develop a desktop application in Java by groups of two, and I enjoyed doing that project. During the summer vacation, it made me want to develop my own desktop application, and since I liked GNOME 2, I wanted my app to be well integrated with GNOME, so I chose to develop it in C with GTK. And now, look where all of this has led me!
2. I didn’t want to fork gedit because it would have duplicated the maintenance, and as a total beginner back then I had difficulties to understand some of the gedit code, because I didn’t know well the GObject library.