Sébastien Wilmet

Two Small Fundraisings – on gspell and LaTeXila

Posted on September 17, 2016 by swilmet

We live in a world where it’s increasingly possible to have a part-time job and being paid for other small tasks on the side; think about Uber or airbnb.

I have a half-time job, and I care about Free Software. So the natural thing to do for me is to find ways to be funded for the contributions I do.

That’s why I was really pleased to hear Alexander Larsson, at the end of his talk at GUADEC about Flatpak:

[…]
And also an interesting thing – I think actually super important – is payment. I want people to be able to pay for Free Software.

Which was met with applause. But unfortunately such support in Flatpak and GNOME Software are not going to happen anytime soon, maybe in a few years with some hope.

In the meantime, I’m launching two small fundraisings!

If this is successful, the idea is to add further milestones, after the work is done on the first one.

gspell

gspell is a library that I created last year to share the spell-checking code between gedit and LaTeXila. The code comes from the gedit spell plugin, as such there is only the support for GtkTextView. The goal of the fundraiser is to add support for GtkEntry, a single line text entry field.

Go to the gspell fundraising page if you’re interested!

LaTeXila

GTK+ 3.22, which will be released this Wednesday, will be the last GTK+ 3 stable version (see this announcement). After that, the deprecated functionality of GTK+ 3 will be removed. LaTeXila is not a new application, it is developed since 2009. A fundraising on a new piece of software can concentrate on features. For LaTeXila, what is more important is that it is well maintained, to be still relevant in the 2020’s. So the fundraiser is to make the code ready for GTK+ 4, at least as a next step.

Code maintenance is not really what we can call interesting, but it is useful. We can see this interesting/useful dichotomy quite often in the computer science world: for a researcher, is proof of correctness interesting? Yes. But in practice it is rarely applied. Is writing unit tests interesting? No, but it is very useful.

Go to the LaTeXila fundraising page if you’re convinced ;)

Posted in gspell, LaTeXila | 5 Comments

Announcing Gtef, an incubator for GtkSourceView

Posted on September 10, 2016 by swilmet

Gtef – the acronym for “GNOME Text Editor Framework” – is a new library that eases the development of GtkSourceView-based text editors and IDEs. It can serve as an incubator for some GtkSourceView features.

See the Gtef repo on GitHub for more details. In particular, Gtef has an interesting way to handle API (un)stability. The Gtef Roadmap is alongside the GtkSourceView one.

Posted in Gtef, GtkSourceView | 2 Comments

Using the GtkSourceView API to write scripts that manipulate text

Posted on August 17, 2016 by swilmet

In the gnome-c-utils repository, I wrote some scripts that use the GtkSourceView library.

When a script needs to read some text, search something in it, and possibly edit the content, then having a GtkTextBuffer is really convenient.

GtkTextBuffer is good at navigating through text, with all the GtkTextIter functions. The content can be edited easily. And the GtkSourceView library adds interesting features like regex search & replace and file loading and saving with character encoding handling (GtkTextBuffer accepts only valid UTF-8).

So, that’s it. I just wanted to share that I find it convenient to write scripts with GtkSourceView (but maybe because I speak the GtkTextView/GtkSourceView API fluently).

Posted in GtkSourceView | Leave a comment

Semi-Object-Oriented Programming in C

Posted on July 14, 2016 by swilmet

Although I said last year that I’m not the right person to write a book about developing GLib/GTK+ applications and libraries, I continue slowly but surely.

There is now a new section called “Semi-Object-Oriented Programming in C”. This serves as a nice warming up for GObject.

Download the PDF:

The GLib/GTK+ Development Platform (version 0.5)

See also the NEWS file to know what changed since my last blog post on the subject.

Any comments or patches are welcome (the Git repo is here).

Posted in book | 2 Comments

Thoughts on the Linux Mint X-Apps forks

Posted on June 18, 2016 by swilmet

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.

Posted in gedit, gspell, GtkSourceView, Programming, Thoughts | 12 Comments

Doing things that scale

Posted on April 23, 2016 by swilmet

In the software world, and with internet, we can do a lot of things that scale.

Answering a user question on IRC doesn’t scale, only one person and a few lurkers will benefit from it. Answering a user question on a mailing list scales a little better, since the answer is archived and can be searched for. What really scales is instead to improve the reference manual. Yes, you know, documentation. That way, normally the question will not surface again. You have written the documentation once and N readers benefit from it, regardless of N. It scales!

Another example. Writing an application versus writing a library. Writing an application or end-user software already scales in the sense that the programmer writes the code once, but it can be copied and installed N times for almost the same cost as one time. Writing a library scales more, since it can benefit N programs, and thus N^2 users if we use the asymptotic notation. It’s no longer linear, it’s quadratic! The lower-level the library, the more it scales.

Providing your work under a free/libre license scales more, since it can be re-distributed freely on the internet. There are some start-ups in the world that reinvent the wheel by writing proprietary software and provide technical support in their region only. By writing a free software instead, other start-ups can pop up in other regions of the world, and will start contributing to your codebase (if it’s a copyleft license, that is). For the human being advancement, free software is better since it more easily permits to not reinvent the wheel. Provided that it’s a high-quality software.

This can go on and on. You get the picture. But doing something that scales is generally more difficult. It takes more time in the short-term, but in the long-term everybody wins.

Posted in Programming, Thoughts | Comments Off

API vs ABI

Posted on April 23, 2016 by swilmet

I repeatedly see other people doing the mistake, so a little reminder doesn’t hurt.

API: Application Programming Interface
ABI: Application Binary Interface

The difference can be easily explained by knowing what to do for some code when the API or ABI breaks in a library that the code depends on:

If only the ABI breaks, then you just need to re-compile the code.
If the API breaks, you need to adapt the code.
When the code doesn’t compile anymore, you need to adapt it, so it’s both an API and ABI break.
When the code still compiles fine but you need to adapt it, it’s only an API break.

Example of an ABI break only: when the size of a public struct changes.

Example of an ABI and API break: when a function is renamed.

Example of an API break only: CSS in GTK+ 3.20, or when a function doesn’t do the same as what was documented before (in an incompatible way).

That’s it.

Posted in Programming | 6 Comments

Libtool convenience library to unit test private functions

Posted on April 17, 2016 by swilmet

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.

Posted in gspell, GtkSourceView, Programming | Comments Off

gCSVedit now hosted on SourceForge

Posted on April 5, 2016 by swilmet

I don’t know if you remember, but I announced in November a small project, called gCSVedit. It’s a small text editor for viewing and editing CSV, TSV, etc files.

I’ve released the 0.2 stable version recently. It is at least now consumable outside Jhbuild.

And, gCSVedit is now hosted on SourceForge instead of GitHub. Because SourceForge is cool again. The forge of SourceForge is free software, unlike GitHub. The users (will) download the tarballs/bundles/installers that *I* have generated, not what GitHub thinks is good to ship. And if the need arises, I can open a mailing list.

Also, I like how each software on SourceForge has a consistent set of information, presented with the same template. You just need to fill up a form with the name, a short description, a long description, the license, a screenshot, an icon, some tags, and such like. It’s better than a README.md file or copying a wiki template manually (if the template is modified, the changes are not echoed…).

The missing thing (both on GitHub and SourceForge, but not on gnome.org) is for the art of (not) managing translations, from the maintainer’s point of view. But a service like Transifex can fill the gap I think.

Posted in gCSVedit | 5 Comments

gspell news bis

Posted on March 9, 2016 by swilmet

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