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!

Posted in gspell | Comments Off on gspell news bis


This is a more personal blog post. Sometimes all those GNOME programming projects are driving me crazy. These last few weeks I needed to rest (that’s why I came only one afternoon at the Developer Experience hackfest, and why I didn’t come to FOSDEM this year (although living nearby)). Yeah, it can happen.

It was time to change a little my focus.

Over the years I created or got involved in more and more projects. When we want to go in too many directions, we make little progress in each. So it’s better to focus only on one or a few projects, and try to make significant progress in those.

Projects that I will no longer actively develop or maintain (at least not during my free time):

Project that I want to “finish” this development cycle:

Project that I’m excited about for the next development cycle:

Other projects that I care about and that I want to do in the future, without any guarantees:

  • Improving file printing in gedit, to be like in Firefox
  • Write a new chapter in my GLib/GTK+ tutorial

Note that for that last item, I would use LaTeXila of course, so if there are some regressions due to some library changes (you perfectly know which library in particular I mean), I’ll probably become aware of the regressions and fix them. Without any guarantees, I repeat. So if someone wants to take over LaTeXila maintenance, I would be more than happy. In the condition that I can still recognize my old pet project afterwards and is still mostly bug-free.

Cat non-fooding

Why such a change of focus? Devhelp was initially a side project for me, and making the gedit source code more re-usable was my main focus during these last years (but along the way it involved also fixing bugs, improving the code readability and making the codebase less a mess, basically).

To explain the refocus, some facts/timeline:

  • I’ve almost always used Vim to program in C.
  • For LaTeX I also used Vim, but at some point I discovered Kile (a Qt application) to write LaTeX documents, because for LaTeX I found that a GUI application has some convenient features.
  • During the summer 2009, I started to write LaTeXila – a new LaTeX editor based on GtkSourceView – to have a LaTeX editor following the GNOME philosophy and based on GTK+.
  • I discovered Vala, and there was a nice gedit plugin for the Vala auto-completion, so I ended up using gedit to develop LaTeXila.
  • At some point I started to contribute to GtkSourceView to fix some bugs, and I used Vim since it is written in C.
  • I got hooked to GtkSourceView development and became a co-maintainer, with the project to make more code of gedit re-usable, to share more code between gedit and LaTeXila.
  • Then my dislike about Vala was growing and growing.
  • I’m no longer a student, so I now rarely use LaTeX.

Basically, I now use gedit mainly for non-programming text editing tasks, e.g. drafting a blog post. In fact, the spell checking is more convenient to use with a GUI application than with Vim. Another use-case of gedit for me is to print a text file. That’s it.

And cat-fooding is important (I’m more a cat person, so I prefer to talk about cat-fooding, or the lack thereof).

For programming, I’m now used to my tmux session with a ‘git’ tab, a ‘build’ tab and several files opened in Vim in the following tabs. I can do everything with the keyboard. I can program during one hour without touching the mouse. I think I would be much less productive if I come back to a terminal + gedit.

But I’m convinced that specialized text editors would be easier to use and configure for the first time than a general-purpose text editor with plugins, tons of options, lengthy configuration files, and such like. And developing libraries to ease the creation of new text editors was an interesting technical project to me.

Anyway, Devhelp is an application that I heavily use. So that’s why I want to improve it. And it’s still in the Developer Experience field. And with the Vim mode of GNOME Builder, I’ll maybe come back one day to a GUI text editor for programming.

Petula Clark – Downtown

Posted in Me Myself and I | 6 Comments

Task-oriented desktop and applications?

I wanted to add a comment to Allan’s blog post The next big thing, but too late! comments are already closed (side note, I think it’s a general problem on or it’s a WordPress issue, or both).

So, at Flock 2014, Langdon White talked about “Fedora for Developers” (video), with the following idea, among other things: Desktop integration with “tasks” (with saved state).

It reminded me about a discussion that I had with gedit developers back in 2011. We talked about profiles: being able to create different gedit profiles, for example one for the C language and one for Vala. Different gedit instances could be launched with different profiles. They would behave as independent apps, with different settings, different plugins activated, a different UI state, and so on. Of course a profile could be created for each programming project, or… task.

But a task often involves launching several applications. So to resume a complete task quickly, in one step, it either needs some desktop integration, or another application could be responsible to create tasks and resume them. But either way it needs coordination with applications.

Posted in Thoughts | 8 Comments

gspell news

  • gspell is now fully hosted on!
  • 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.

Posted in gedit, gspell | 3 Comments

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 files.

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

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 naturally.

Future plans

Create an installer for Windows. 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 was hosted on GitHub, but it is now hosted on SourceForge. So the URLs have been updated.

Posted in gCSVedit, gedit, GtkSourceView | 7 Comments

LaTeXila 3.18 + need of a graphics designer for the app icon

LaTeXila 3.18 has been released last week. There are some nice improvements:

  • New buttons in the integrated file browser (in the side panel) to open the current directory in a file manager (e.g. Nautilus) or in the terminal. Thanks to Arnaud Blouin, the developer of LaTeXDraw.
  • Better read-only mode for the default build tools. Only the personal build tools can be modified, the default build tools are read-only. Before, it was confusing because when opening a default build tool, it was possible to edit the fields (but the changes weren’t saved). Now the distinction is much clearer.
  • More modern design for the dialog windows.

Creating a new LaTeX project

But the most important news is for the spell checking, which has been significantly improved this development cycle:

  • A new library called gspell has been created. The source code comes from gedit. Read this blog post for the technical story.
  • The LaTeX commands are no longer marked as misspelled.
  • In the preferences dialog, you can change the default settings for the spell checking: the language and whether misspelled words are underlined in red in the document.
  • Via the Tools menu, the spell checking settings can be changed and are stored on a file-by-file basis.
  • There is now a spell checker dialog window, to spell check an entire file.
Spell checking in LaTeXila 3.18

Spell checking in LaTeXila 3.18

The spell checking improvements have been possible thanks to the fundraiser, so thanks a lot for your support!

Speaking about it, the fundraiser has been re-targeted. Unfortunately the €10,000 milestone has little chances to be reached. That milestone included lots of LaTeX-specific improvements to LaTeXila. Now the fundraiser focuses more on the usefulness for other text editors, not just for LaTeXila. For example gspell will be useful for a lot of other GTK+ applications where the spell checking is needed.

Need of a graphics designer for the app icon

Since several years, LaTeXila is a quite good and stable LaTeX editor for GNU/Linux. It’s a lightweight but feature-full editor, that don’t gets in the way.

LaTeXila icon

But, the application icon is still quite ugly. For the visual identity of LaTeXila, it would be better to have a better icon. Since I’m not good at graphics design, I need some help. If anyone is interested, please contact me!

Thanks in advance!

Posted in gspell, LaTeXila | Comments Off on LaTeXila 3.18 + need of a graphics designer for the app icon

Changing quickly between a final and derivable GObject class

When doing code refactorings, it is sometimes desirable to change between a final and derivable GObject class. So it is important that that operation can be done quickly, as every other small refactorings that you usually do in your code.

In fact, when refactoring some code, sometimes you want to quickly try something to see if the result is better. But if a certain refactoring task takes a lot of manual and boring steps, (1) it’s not a pleasure to do it and (2) if the result (after other refactorings) is not what you want, you’ve lost your time.

To evolve in the right direction, a code needs to be easily modifiable.

With the convention to put GObject instance variables in the Private struct for derivable types, and in the object struct for final types, changing between the two is currently quite burdensome (because there is no tools to do it quickly):

/* For a final type */
my_object_get_foo (MyObject *object)
  return object->foo;

/* For a derivable type */
my_object_get_foo (MyObject *object)
  MyObjectPrivate *priv = my_object_get_instance_private (object);

  return priv->foo;

Maybe in a library like GTK+, changing between a final and derivable type is not a common operation. But in an application, it can be more common. For example when you want to move a class from an application to a library (it can be an internal or external library), one way to do it is to move the re-usable code in the library and keep the app-specific code in a subclass. So in that case, the class in the library needs to be derivable!

There is, though, another convention that can be used with GObject: always use a Private struct, even for final types.

But, calling my_object_get_instance_private() in each function is quite cumbersome… With the old convention to have a 'priv' field in the object struct to access the Private struct, you don’t have that problem. For example:

/* Old convention: have a 'priv' field in the object struct. */
my_object_get_foo (MyObject *object)
  return object->priv->foo;

Although for a library it’s better to not have the 'priv' field, I tend to prefer that latter code.

TL;DR: writing and refactoring GObject code in C can be quite painful, we need more tools. In the meantime, there can be a big difference just by following a different convention.

Edit: If you’ve read this blog post, you might think “just use Vala or Python or JavaScript! problem solved!”, but I still prefer the C language for GNOME development for reasons explained in this document. And to develop a library, the C language is the de facto language in GNOME.

Posted in Programming | 6 Comments

Introducing gspell, a new spell checking library

As part of the LaTeXila project and its fundraiser, 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!

Update: gspell is now hosted on, the links above have been updated. The project page is now at

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.

Posted in gedit, gspell, GtkSourceView, LaTeXila | 5 Comments

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…

Posted in book | 5 Comments

Fundraiser campaign for LaTeXila

It was already possible to make a donation for LaTeXila since March 2014. There was just a link on the web site and an entry in the Help menu. But I made almost no advertising for that. Now for the 3.16 release I would like to push the accelerator one step further!

LaTeXila is already a mature and stable application, it doesn’t miss much to become a LaTeX editor of choice (if it isn’t already the case). Some features need to be a little improved, especially the spell checking. And a few features are missing (I’m looking at you, live preview).

So, if you are a LaTeX user and wants a great editor for writing your documents, don’t miss the LaTeXila fundraiser campaign!

Note that some of the planned items would be useful for other text editors as well, since the work would be done in an underlying library (GtkSourceView, GtkSpell, …).


Posted in LaTeXila | 9 Comments