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.

Libtool convenience library to unit test private functions

Only the public API of a library is exported, so when a program is dynamically linked to the DSO (Dynamic Shared Object), it can only use the public functions.

So how do you unit test the private classes of your library?

There is a simple solution, having a Libtool convenience library that contains the whole code of the library, but without an -export linker flag, so that all functions can still be accessed. You then link that *.la file to your unit tests and also to the real library where you add the appropriate -export flag.

You can see that in action in GtkSourceView and gspell. For example in gspell:

When you run make in verbose mode with make V=1, you see that the libtool commands statically link the convenience static library (a file with the *.a extension) into the unit test programs and into the DSO.

That way the *.c files are compiled only once, and adding a unit test to the testsuite/Makefile.am is straightforward.

gspell news bis

Some more gspell news (see the previous iteration):

  • gspell has been re-licensed from GPLv2+ to LGPLv2.1+.
  • gspell no longer depends on the libxml2 and GtkSourceView libraries.
  • gspell 1.0 will be released at the same time as GNOME 3.20 (in a few weeks), with a stable API.
  • There has been several iterations on the API, making it easier to use. See below.
  • In gedit 3.18 there was a regression: the current word being typed was spell checked… which is now fixed, because it was annoying to have a red wavy underline appearing constantly while typing…
  • Words with apostrophes – like “doesn’t” – are now supported!
  • And a testsuite has been written.

API design

See the gspell API reference. There are two things worth mentioning that are generally useful when designing APIs.

First, a constraint has been directly translated into the API itself instead of allowing an illogical combination in an application.

More specifically, for the same GtkTextBuffer, it doesn’t make sense to use a different GspellChecker between an inline checker and an “external” checker (e.g. a dialog window). Since it’s the same GtkTextBuffer, it should be the same GspellChecker to share the session dictionary (when you click on Ignore All, the word is added to the session dictionary). So instead of having a spell-checker property on both the inline checker and the external checker, now a GspellChecker must be attached to a GtkTextBuffer with gspell_text_buffer_set_spell_checker(). That latter function takes a GtkTextBuffer argument, there is no GspellTextBuffer subclass since there is already one in the GtkSourceView library. That’s where g_object_set_data() becomes useful. And by attaching the GspellChecker to the GtkTextBuffer, we no longer need to keep the GspellChecker object around in the application code, we can get it with gspell_text_buffer_get_spell_checker().

The other thing worth mentioning is that at another place a class is more lax and accepts a certain state instead of documenting “please check the value of …”. More precisely, GspellChecker now accepts a NULL language in the case there are no dictionaries installed.

One of my goals when developing gspell is also to learn writing good APIs, so if you see some possible improvements, don’t hesitate! It’s too late for the 1.x versions, but I can keep a bug around on bugzilla with the 2.0 target. And of course, any other comments or testing are welcome.

Thanks to Paolo Borelli for the API review, and thanks to the numerous GNOME translators! gspell 1.0 will be rock solid!

gspell news

  • gspell is now fully hosted on gnome.org!
  • There is now a mailing list.
  • In addition to LaTeXila, gspell is now also used by gedit (5,800 lines removed, yay!).
  • The 0.1.x version has branched and is meant to be installed alongside GNOME 3.18.
  • If everything goes fine, the 1.0 version will be released at the same time as GNOME 3.20, with a stable API.

API reviews are more than welcome!

Stay tuned.

Announcing gCSVedit, a simple text editor to edit CSV files

As part of my job at the Université Catholique de Louvain, one of my projects is to develop gCSVedit, a small and simple text editor to edit CSV/TSV files.

gCSVedit is now a free/libre software (GPLv3+ license) and is hosted on GitHub.

Other delimiter-separated values (DSV) files are supported, not just comma-separated values (CSV) files, but “CSV” is more commonly used to refer to that kind of file.

Screenshot of gCSVedit
gCSVedit with the columns aligned. Note also the gray bullets to represent the spaces present in the file.

Why developing a new application for editing CSV files?

CSV files can already be opened in a spreadsheet software like LibreOffice Calc and Gnumeric. But it’s not really user-friendly. Just to open the file you need to provide tons of options:

Screenshot of opening a CSV file with LibreOffice Calc
Opening a CSV file with LibreOffice Calc

A general-purpose text editor like gedit is not the best choice either, because the columns are not aligned. There are some plugins for Eclipse or other IDEs available, but launching and using a complete IDE just to view or edit a CSV file is not user-friendly either.

The best is a specialized application, to do just one thing but do it well. With a user interface that goes straight to the point.

Spreadsheet or text editor?

With a text editor, all characters are visible, including the delimiters. We have thus a greater control. When writing a script to extract the data contained in the file, it’s important to view every character in case of problems (like an extra separator in the data but not for the column titles).

Also, some software that generate CSV files sometimes also include an header, i.e. some text before the actual CSV fields. With a text editor, the header can be shown in a natural way.

Future plans

Create an xdg-app for GNU/Linux. And implement more features of course!

Hopefully in the future it’ll be possible to re-use more code of gedit, to have a decent text editor (although gCSVedit is already completely usable).

So, nothing revolutionary here, it’s a small project. But I think it can bring a better usability. Comments, questions?

PS: to show where are the real spaces (those present in the file, not those added for the alignment), I’ve already contributed to GtkSourceView and GTK+. There will maybe be more contributions in the future, for example to implement a utility to insert virtual spaces, i.e. the text editor should behave as if the added spaces didn’t exist. Or, finally implement rectangular selection in GtkTextView.

Edit: gCSVedit has moved several times where it was hosted, I’ve updated the above URLs.

Introducing gspell, a new spell checking library

As part of the LaTeXila project I’m working on a new spell checking library called gspell.

Some background

At first I wanted to contribute to GtkSpell so that GtkSpell and GtkSourceView work well together, without a dependency on each other. GtkSourceView defines a no-spell-check region. For LaTeX, the region includes the LaTeX command’s names, for example. But GtkSpell didn’t read that region, and the region was available only through the GtkSourceView API. Adding a dependency on GtkSourceView in GtkSpell was not desirable, because many applications use GtkSpell only. Also, a library like GtkSpell could potentially add the support for GtkEntry too, so if there is a dependency on GtkSourceView, it isn’t nice for an application that wants only the spell checking for a GtkEntry. The solution was actually really simple: the no-spell-check region is a GtkTextTag. After setting a name to the tag and expose it in the API, it was possible for GtkSpell to lookup the tag and read the region.

So the patches for GtkSourceView and GtkSpell have been merged, to remark only later that there was a quite annoying text responsiveness problem on long lines (e.g. a wrapped line that takes 5 lines on the screen). And… there was exactly the same problem with the gedit spell plugin. The typed text appeared with a noticeable delay. Fixing that problem was more complicated. The text needs to be spell checked after a timeout. But adding a timeout function means that the remaining region to spell check needs to be tracked, which was not the case, neither in GtkSpell nor in gedit. And another problem is that GtkSpell anyway needed some code clean-ups. On the other hand the gedit code was in a slightly better shape and, more importantly, it had more features. For example gedit has a dialog window to spell check an entire document, one (misspelled) word at a time, whereas GtkSpell only has an “in-line” checker. An in-line checker is not convenient in the case of a very long document with very few misspelled words, in that case the dialog window is more convenient (btw it could also be an horizontal bar above or below the text, to not hide the text by the dialog window).

So, since the gedit spell plugin’s code had more features, I’ve decided to improve that code base instead. The gedit plugin code also needed some code clean-ups, but at least the code architecture was for the most part good. After those code refactorings and bug fixes, it was easier to fix the responsiveness problem. Then, after some more “spell shaking” (haha) the code was re-usable for other text editors.

Enters gspell

The gedit spell plugin’s code has then been copied into its own repository, called gspell. The library is still under construction, but I hope to get a first version available when GNOME 3.18.0 is released (September 21, according to the schedule). That first version will not have a guaranteed stable API, be warned! It is currently available on my GitHub account, but if things go well, I’ll ask during the next development cycle to get it hosted on gnome.org!

Update: gspell is now hosted on gnome.org, the links above have been updated. The project page is now at https://wiki.gnome.org/Projects/gspell.

What it means for LaTeXila

Basically, the LaTeX command’s names won’t be highlighted anymore with a red wavy underline. And there will be a dialog window to spell check an entire file. Also, on the LaTeXila side, settings will be stored on a file-by-file basis (to remember the language and whether the in-line checker is activated), and there will be settings in the preferences dialog for the default configuration.

I already have a branch in LaTeXila that uses gspell, and it works pretty well. There is still a bit of work to do, but it should be ready soon. Since it would be a pity to not have it for LaTeXila 3.18, I’ll delay the release of LaTeXila 3.18.0 for a few weeks to let translators have the time to update the translations.

An introduction about writing GLib/GTK+ applications in C

GNOME lacks a good and recent book about writing applications and libraries. I was motivated, some months ago, to write such a book. But this motivation has dissipated somehow, I don’t think I’m the right person.

Anyway, here is my attempt:

The GLib/GTK+ Development Platform (version 0.2)

It contains an introduction to GLib, which is mostly an updated version of the corresponding chapter in GGAD, written by Havoc Pennington (with his permission).

Even if the document is short, I think it can already be an interesting read. With the hope that the content can be reused for a real book in the future…

Thoughts on live previews in LaTeXila

Several years ago I talked about some principles for the user experience of LaTeXila, a GTK+ LaTeX editor for GNU/Linux. The conclusion:

The idea of LaTeXila is to always deal directly with the LaTeX code, while simplifying as most as possible the writing of this LaTeX code. The users don’t need to be LaTeX gurus, but they should understand what happens.

In my opinion this better follows the LaTeX philosophy than programs like LyX. By writing directly the LaTeX markup, you have full control of your document. The idea of LaTeX is to concentrate on the content and the structure of the document, not its layout.

With a live preview, you see constantly the layout… so you’re less concentrated on the content. As soon as something is wrong in the layout, you’ll want to fix it. This can lead to bad practices, like proceeding by trials and errors until the layout is good. LaTeXila tries to avoid that. As in programming, you should understand what you’ve written before the compilation or execution. You must be certain that the code is correct; if you have any doubts, the best is to read the documentation, this will save you time when you’ll use the same commands in the future.

Moreover, layout polishing should be done when the content is finished. For instance, it can sometimes happen that a word exceeds the margin, because LaTeX doesn’t know where to place an hyphen to split that word. It is useless to fix this issue when the content isn’t finalized, because if you add or remove some words in the sentence, the problem will maybe be fixed by itself.

Instead of a live preview, the workflow in LaTeXila is to compile from time to time the document (e.g. when you’ve finished a section) to re-read your text and check that the result is what you expected. A handy feature in that context is the forward and backward search between LaTeXila and Evince, to switch between the *.tex file(s) and the PDF at the corresponding positions, with a simple Ctrl+click.

But there are some special cases where a live preview can be useful, i.e. when more source <-> result cycles are required:

  • A PGF/TikZ figure preview, because in that case the layout is more important.
  • When we do something difficult, like writing a long and tricky math equation. But when it becomes difficult to find our way in the code, an alternative is to improve its readability, by spacing it out, adding comments to separate the sections, etc.

If you have other specific use cases where a live preview is really useful, I would be interested to hear them. I don’t think “learning LaTeX” requires a live preview, as explained above this can result in bad practices.

So I think a live preview might be useful for editing one paragraph. A live preview of the whole document is probably less useful. In any case, a live preview should be enabled only temporarily. In LaTeXila we can imagine doing a right click on a paragraph or TikZ figure, select the live preview in the context menu and we enter in a mode where only that paragraph (or selection) is visible, with the live preview on top/right/directly injected in your brain/whatever. Then when the writing of the tricky paragraph is finished, we return to the normal mode with the whole source content.

File loading and saving in GtkSourceView, finally

Last year GtkSourceView saw a new search and replace API. This year it’s the file loading and saving that has just landed! It is in the continuity of making the gedit source code more reusable for other text editors.

In short, the back-end part of the file loading and saving in gedit has been moved to GtkSourceView, with a new and more flexible API to better wrap the feature. The code has been modified to follow GIO conventions for asynchronous operations, to use GTask internally, and replace the uses of GSettings by properties, among other things.

The file loader auto-detects encodings, newline types and compression type (yes gedit can open gzip files). Invalid characters can also be displayed with their corresponding hexadecimal value, because GtkTextBuffer accepts only valid UTF-8 text. And progress information is reported during the operation.

The API is stateful: the file parameters (encoding etc) are remembered between a file loading and a file saving in a GtkSourceFile object. Unfortunately the new API is still quite low-level. The application must configure the file loader and the file saver, and some errors are returned to the application.

So the front-end and errors handling is still implemented in gedit. Errors and progress information are displayed in an info bar, above the GtkSourceView widget. For some errors, gedit proposes different actions to the user, like choosing another encoding.

API design

If you are a text editor developer, don’t hesitate to have a look at the GtkSourceFile API. The API can still change during this 3.13 development cycle. The notes about the API design are available on bugzilla (there has been four iterations). Here is a summary.

The API is a bit heavy, with the following classes: GtkSourceEncoding, GtkSourceFile, GtkSourceFileLoader and GtkSourceFileSaver. There are good reasons for having two class’ names derived from a verb (“to load” and “to save”), which is generally a hint that those classes should be replaced by a method (i.e. an action). The reasons are partly similar with the new GSubprocessLauncher in GIO: the FileLoader and FileSaver classes are there not only for launching the operation, but also for configuring it with a nicer and more extensible API than one function with a dozen parameters. With the FileLoader and FileSaver, we can add properties, functions and even signals. And the FileLoader and FileSaver classes are quite useful in gedit: when an error occurs and the user clicks on a button in the info bar, the loader or saver object is reconfigured and the operation is relaunched, without the need to keep the initial configuration around. Also, the FileLoader or FileSaver properties are applied to the GtkSourceFile object only on a successful operation, so the GtkSourceFile state is (normally) consistent with the underlying file on the disk, at least at the time of the last load or save done with GtkSourceView.

Possible follow-ups work

A possible follow-up is to make the front-end code more reusable, either by creating higher-level classes in GtkSourceView, or by creating a git submodule, like the libgd (without API stability guarantees in the latter case).

Another possible follow-up is to analyze and improve the performances, which are currently quite bad. For short files it is not visible of course, but opening a very big log file takes more time than with other popular text editors.

There are other possible improvements, like unescaping invalid characters when saving, or avoid blocking the GtkTextBuffer when (auto-)saving a short remote file on a slow network connection.

Changes for gedit plugins

Unfortunately there are some changes in the gedit API for plugins, mainly in GeditDocument. Fortunately the changes are well documented, and most plugins should still work without any modification.

Conclusion

The file loading and saving can quickly become a fairly complex beast. Now this code is available for other GTK+ text editors.

Thanks to Paolo Borelli for the reviews!

TL;DR:

  • In GtkSourceView: 29 files changed, 7909 insertions(+), 3 deletions(-)
  • In gedit: 49 files changed, 1888 insertions(+), 8819 deletions(-)
  • In gedit-plugins: 11 files changed, 22 insertions(+), 31 deletions(-)

This is a 12% code increase in GtkSourceView, and a 6% code decrease in gedit.

PS: As usual, some tests would be more than welcome before the stable version in September.

Making the gedit source code more reusable

On IRC I see some developers working on other text editors based on GtkTextView/GtkSourceView. It is a good thing in my opinion to have specialized text editors. They are easier to use and configure. A specialized application has a potentially better usability. A general-purpose text editor like gedit is of course still needed for languages not covered by a specialized text editor or IDE.

The problem is that creating a new text editor based on GtkSourceView is still quite a lot of work. Instead of reinventing the wheel, the idea is to make the gedit source code more reusable by moving it to GtkSourceView or to a git submodule. This wiki page has all the details, it keeps track of the progress made (see also the RoadMap), more details on the “why?”, and a paragraph on Anjuta.

This blog post was to make developers aware of this initiative. If you are interested, join us on the #gedit channel or the mailing list!