Sébastien Wilmet

A new beginning

Posted on December 13, 2018 by swilmet

These past months I was more and more thinking about changing my career as a software developer. I started to contribute to open-source when I was a student because it was something fun to do. I like programming, practicing, and the sharing philosophy of Linux and open-source.

I’ve learned really a lot of things by contributing to GNOME, trying to always improve myself, finding gaps in my knowledge and then reading some books to fill those gaps, and have more and more ambitious projects over time.

As a GNOME developer there are sometimes some job opportunities, but I prefer to stay in Belgium, I don’t really want to relocate to another country. Some open-source developers do teleworking 100% of the time, and they see their colleagues only when going to conferences or hackfests. It’s not something that I want to do, I like working at home to be less distracted, but maybe two days per week, not all the time.

Since four years I have a half-time job, which permitted me to continue my contributions to GNOME the rest of the time, doing crowdfunding to earn a little more. But my situation is not sustainable in the long run, the crowdfundings were not really successful, maybe because I’m not good at marketing, or just because Linux desktop users are accustomed to get everything for free.

So I’m now looking for a new job! This is an opportunity for me to try something new, to get out of my comfort zone. The elephant in the living room is that almost nobody do desktop application development these days, everybody do web, mobile or embedded development. So my future work will probably revolve around that.

GNOME software product lines

To summarize my work in GNOME these past years, I was actually developing software product lines. My focus was on making more code re-usable, by adding more features to existing libraries, or by creating higher-level, domain-specific libraries.

One software product line was for text editors and IDEs, with a set of libraries (GtkSourceView, gspell, Amtk and Tepl) and a set of applications (GNOME LaTeX, gCSVedit, gedit and Gnotepad).

Another software product line in progress was for the Devhelp API browser, with the libdevhelp and Amtk as libraries. The goal was to keep the Devhelp application generic, and to create a specialized version for GNOME with a few additional features.

Some statistics

Just counting my GNOME or GNOME-related projects, I’m the author of more than 6000 commits and ~140k lines of code, spread across ~30 Git repositories. Some modules that I maintained or created are installed on millions of computers.

Expanding Amtk to support GUIs with headerbar

Posted on April 24, 2018 by swilmet

I initially created the Amtk library to still be able to conveniently create a traditional UI without using deprecated GTK+ APIs, for GNOME LaTeX. But when working on Devhelp (which has a modern UI with a GtkHeaderBar) I noticed that some pieces of information were duplicated in order to create the menus and the GtkShortcutsWindow.

So I’ve expanded Amtk to support GUIs with GtkHeaderBar and GtkShortcutsWindow, and ported Devhelp to Amtk. I’m quite happy with the result, there are fewer lines of code, it avoids information duplication, all the extra information about the GActions are centralized (so inconsistencies are easier to catch), and on top of that Amtk has been designed to be able to share the extra GActions information in a library, so it’ll be possible to provide a higher-level API for the libdevhelp.

Read the Amtk introduction for more details.

PS: oh, and I’ve moved Amtk to its own git repository now, it was initially developed inside Tepl.

Posted in Amtk, Devhelp | Comments Off

Devhelp news

Posted on April 22, 2018 by swilmet

Some news for your beloved API documentation browser, Devhelp!

I’ve written recently a roadmap for Devhelp and its library. It serves as a good summary of what has been achieved recently, with some future plans. Most of what I’ve done so far are under-the-hood changes, so it’s not directly visible in the application, except – hopefully – the better quality/stability (I’ve discovered and fixed a lot of bugs when doing refactorings).

For more context, I started to contribute to Devhelp in 2015 to fix some annoying bugs (it’s an application that I use almost every day). Then I got hooked, I contributed more, became a co-maintainer last year, etc. Devhelp is a nice little project, I would like it to be better known and used more outside of GNOME development, for example for the Linux kernel now that they have a good API documentation infrastructure (it’s just a matter of generating *.devhelp2 index files alongside the HTML pages).

Posted in Devhelp | Comments Off

GtkSourceView fundraising – November/December report

Posted on January 4, 2018 by swilmet

I’ve launched in September a fundraising for the GtkSourceView library. Here is a report for the past two months.

What has been achieved

I prefer to set expectations, I haven’t worked hard on GtkSourceView and Tepl this time around, because the fundraising is not as successful as I would like. Since I’m paid less than one hour per week for that project, I don’t feel forced to work > 10 times more, I think it’s understandable.

But I still continue to maintain GtkSourceView and Tepl, and I’ve progressed a little for the file loading and saving. The tasks that I’ve done in November/December:

Code reviews, especially for *.lang files (needed for syntax highlighting);
Triage incoming bugs on the bug tracker;
Doing releases;
Writing an Uncrustify configuration file to apply the GtkSourceView coding style, it will ease contributions;
Continue the high-level API for the file loading and saving in Tepl;
A few other development tasks in Tepl.

Posted in GtkSourceView, Tepl | Comments Off

GtkSourceView fundraising – September/October report

Posted on November 8, 2017 by swilmet

I’ve launched two months ago a fundraising for the GtkSourceView library. I intend to write a report every two months, so that you can follow what’s going on in that project, and at the same occasion I can explain in more details some facets of the fundraising.

Only one maintainer (me)

For most of the code in GtkSourceView, there is basically only one remaining maintainer: myself. Tobias Schönberg helps to maintain and review some *.lang files (for the support of syntax highlighting), especially in the area of web development. But that’s it.

Here are the top 5 contributors, in terms of number of commits:
$ git shortlog -sn | head -5 1372 Sébastien Wilmet 531 Paolo Borelli 289 Ignacio Casal Quinteiro 200 Jesse van den Kieboom 149 Yevgen Muntyan

So you can see that I’m the first contributor. All the other developers also contributed during their free time, and they don’t have enough free time anymore (they have an unrelated full-time job, etc).

So in some way, the future of GtkSourceView rests in my hands.

File loading and saving

These past weeks my focus was on file loading and saving in Tepl (the incubator for GtkSourceView).

There are several layers for the file loading and saving:

The backend/toolkit part, i.e. the low-level API, it’s what I’ve added to GtkSourceView in 2014 but needs improvements.
The high-level API taking care of the frontend, part of the Tepl framework.
Some features that are built on top of the high-level API, for example an action to save all documents, or the auto-save to automatically save a document periodically.

For the first layer, the backend/toolkit part, Tepl provides two new things: file metadata (for example to save the cursor position) and a new file loader based on uchardet, to improve the character encoding auto-detection. This past month I’ve improved the new file loader, it is now in a good enough shape for most applications (but still lacks some features compared to the old file loader, so some work is still needed to be able to deprecate the old implementation).

For the second layer, I’ve started to create the high-level API. Creating the API is not the most difficult, the bulk of the work will be to improve what the implementation does internally (creating infobars, handling errors, etc).

The third layer has not yet started.

File loading and saving was not the only thing that I did these past two months, a lot of other smaller things have been done, for more details see the NEWS files:

Conclusion

Even if GtkSourceView already provides a lot of features, it is far from sufficient to create even a basic text editor (to have an implementation of a good quality). To give a concrete example, the core of gedit – if we remove all the plugins – is currently made of 40.000 lines of code! It’s a lot of work for a developer who wants to create a specialized text editor or a new IDE.

So my goal with GtkSourceView and Tepl is to make more code re-usable.

See the GtkSourceView fundraising on Liberapay. Thanks for your support!

Posted in GtkSourceView, Tepl | Comments Off

List of GNOME-related projects fundraisers

Posted on October 19, 2017 by swilmet

I think it’s useful to have a list of projects fundraisers in GNOME or at least GNOME-related. Ideally it would be nice to have that list on the gnome.org website, it looks to me an obvious thing to do, but after a discussion on the GNOME foundation-list, it seems unlikely to happen anytime soon.

So I’ve created this wiki page in the meantime. It also explains the difference with donations made to the GNOME Foundation.

The list includes the GtkSourceView fundraiser that I launched last month. I plan to write regular updates on that front on this blog, for example every two months. Stay tuned, and thanks for your support :-)

Posted in Uncategorized | Comments Off

GtkSourceView fundraising!

Posted on September 9, 2017 by swilmet

I’m launching a fundraising for GtkSourceView!

If you don’t know what GtkSourceView is, it’s a widely used library for text editors and IDEs (or text editing in general). For example on Debian, more than 50 applications rely on GtkSourceView, including gedit and GNOME Builder.

What less people know about is that GtkSourceView has been almost entirely developed by volunteer work, without being paid, except a few Google Summer of Code. So with the fundraising it’ll hopefully change, to bring the library to the next level!

Go to the fundraising on Liberapay for more information.

Thanks!

Posted in GtkSourceView | 10 Comments

GObject design pattern: attached class extension

Posted on August 9, 2017 by swilmet

I wanted to share one recurrent API design that I’ve implemented several times and that I’ve found useful. I’ve coined it “attached class extension”. It is not a complete description like the design patterns documented in the Gang of Four book (I didn’t want to write 10 pages on the subject), it is more a draft. Also the most difficult is to come up with good names, so comments welcome ;)

Intent

Adding a GObject property or signal to an existing class, but modifying that class is not possible (because it is part of another module), and creating a subclass is not desirable.

Also Unknown As

“One-to-one class extension”, or simply “class extension”, or “extending class”, or “Siamese class”.

Motivation

First example: in the gspell library, we would like to extend the GtkTextView class to add spell-checking. We need to create a boolean property to enable/disable the feature. Subclassing GtkTextView is not desirable because the GtkSourceView library already has a subclass (and it should be possible in an application to use both GtkSourceView and gspell at the same time¹ ).

Before describing the “attached class extension” design pattern, another solution is described, to have some contrast and thus to better understand the design pattern.

Since subclassing is not desirable in our case, as always with Object-Oriented Programming: composition to the rescue! A possible solution is to create a direct subclass of GObject that takes by composition a GtkTextView reference (with a construct-only property). But this has a small disadvantage: the application needs to create and store an additional object. One example in the wild of such pattern is the GtkSourceSearchContext class which takes a GtkSourceBuffer reference to extend it with search capability. Note that there is a one-to-many relationship between GtkSourceBuffer and GtkSourceSearchContext, since it is possible to create several SearchContext instances for the same Buffer. And note that the application needs to store both the Buffer and the SearchContext objects. This pattern could be named “one-to-many class extension”, or “detached class extension”.

The solution with the “attached class extension” or “one-to-one class extension” design pattern also uses composition, but in the reverse direction: see the implementation of the gspell_text_view_get_from_gtk_text_view() function, it speaks for itself. It uses g_object_get_data() and g_object_set_data_full(), to store the GspellTextView object in the GtkTextView. So the GtkTextView object has a strong reference to the GspellTextView; when the GtkTextView is destroyed, so is the GspellTextView. The nice thing with this design pattern is that an application wanting to enable spell-checking doesn’t need to store any additional object, the application has normally already a reference to the GtkTextView, so, by extension, it has also access to the GspellTextView. With this implementation, GtkTextView can store only one GspellTextView, so it is a one-to-one relationship.

Other Examples

I’ve applied this design pattern several other times in gspell, Amtk and Tepl. To give a few other examples:

GspellEntry: adding spell-checking to GtkEntry. GspellEntry is not a subclass of GtkEntry because there is already GtkSearchEntry.
AmtkMenuShell that extends GtkMenuShell to add convenience signals. GtkMenuShell is the abstract class to derive the GtkMenu and GtkMenuBar subclasses. The convenience signals must work with any GtkMenuShell subclass.
AmtkApplicationWindow, an extension of GtkApplicationWindow to add a statusbar property. Subclassing GtkApplicationWindow in a library is not desirable, because several libraries might want to extend GtkApplicationWindow and an application needs to be able to use all those extensions at the same time (the same applies to GtkApplication).

Why not implementing spell-checking in GtkSourceView then? Because gspell also supports GtkEntry. [↩]

Posted in Amtk, gspell, GtkSourceView, Library development, Programming, Tepl | 3 Comments

Amtk – Actions, Menus and Toolbars Kit for GTK+

Posted on July 20, 2017 by swilmet

GtkUIManager has been deprecated without a good replacement for applications that want to keep a traditional UI (with a menubar, toolbar and statusbar). So I’ve written a new shared library called Amtk, currently developed inside the Tepl repository. It is a basic GtkUIManager replacement based on GAction. If you are interested, read the Amtk introduction (it explains the problems with what GTK+ currently provides and that Amtk solves) and the API reference.

Note that the library is not yet finished, factory functions are missing, release early release often etc. But I think that what remains to be done is not a lot of work (for my needs at least).

Posted in Amtk, Tepl | 1 Comment

Gtef library renamed to Tepl – Text editor product line

Posted on June 15, 2017 by swilmet

Gtef (GTK+ text editor framework) has been renamed to Tepl (Text editor product line). The end of Tepl is pronounced like in “apple”.

I didn’t really like the name Gtef. And since the project is still young, it was easy to rename everything.

I’ve also written a more complete introduction.

The name “Text editor product line” was inspired by this book: Feature-Oriented Software Product Lines. It’s an interesting book, I’m learning new things, like the difference between a white-box framework and a black-box framework, or cross-cutting concerns (and how to better handle them), etc.

Posted in Tepl | Comments Off