The website of Gedit Technology has been created in 2022 and is now hosted where the link points to. However, the actual code behind it is older than that. Read on for a retrospective and the important dates and milestones.
First, what is it? The project web page describes it this way:
Gedit Technology is based on the GTK graphical toolkit and provides the main components behind the gedit text editor.
gedit is the application (for end users), Gedit Technology is the re-usable code provided as a set of libraries (for developers).
gedit is closely related to some libraries. The list, alongside the year of the project creation:
Initially, GtkSourceView didn't come from the gedit codebase, but once created gedit has quickly adopted it. Then the two projects were developed side by side. Its main feature is syntax highlighting, but lots of other features have been added over the years (small ones like displaying the line numbers in the margin, and bigger ones such as a completion framework).
libpeas is the plugin engine, used by other applications like the Totem video player. It is a gedit developer who decided to factor out a library from the gedit codebase. Before that, application authors copied (and modified) the implementation from another app, so in GNOME there were lots of different variants.
gspell is for the spell-checking. Its code comes from a gedit plugin. The plugin still exists but is much smaller now. The purpose was to share code between gedit and GNOME LaTeX (another text editor that targets the TeX/LaTeX languages). The gspell library has been used by numerous other GTK applications, including GNOME Software (the software center).
libgedit-tepl is not as widespread as the other projects, but is the continuation of GtkSourceView with more experimental APIs. The goal is to be able to iterate on the APIs more freely.
libgedit-amtk and libgedit-gfls are small additional libraries. The first one is all about Actions, Menus and Toolbars (Kit). The second one is about File Loading and Saving but is in its early infancy.
Note the "libgedit" prefix. Some projects were first created without it and have been renamed since. The prefix permits to better identify the project origins or to what it belongs. Since the number of such projects was growing, having more and more disparate names was not really convenient, especially for packagers.
Now on an up-to-date Linux distribution, you can search the packages database for "gedit" or "libgedit". Or during updates, if you see "libgedit-something", you know what it is.
The more recent developments in gedit focused on re-usability and refactoring. By doing this little exercise, we believe that the code has a better quality: a better architecture (most importantly), smaller classes with more separation of concerns, fewer bugs, more unit-testable code (and unit-tested), and much improved documentation.
Thank you for reading!
This article was written by Sébastien Wilmet, currently the main developer behind Gedit Technology.