|
|
|
|
libgedit-tepl is a library that eases the development of text editors and IDEs based on GTK. Tepl is the acronym for “Text editor product line”.
The libgedit-tepl library follows a product line approach, inspired by Feature-Oriented Software Product Lines: Concepts and Implementation (2013 - Apel, Batory, Kästner and Saake).
Instead of creating one general-purpose text editor or IDE with a plugin system, the idea is to create several specialized text editors. For example specialized for one programming language, or one development platform, or a small group of related languages. By being specialized, an application is potentially better at what it does. It follows more closely the UNIX philosophy to “do only one thing but do it well”. And it better follows the GNOME philosophy: writing applications that Just Works; when a user opens the text editor for the first time, it should work out-of-the-box, without the need to find, install and configure plugins. Of course it still makes sense to develop one general-purpose text editor for the languages not yet covered by specialized text editors.
Most of the features of the library are available as a toolkit, but the interesting part of libgedit-tepl is that it contains also a framework (for now without a plugin system). The goal of the framework is to provide higher-level APIs, to be able to create a new text editor easily. An application wanting to use libgedit-tepl is not forced to use the framework in its entirety, it is possible to use just the toolkit parts. The library is implemented this way to achieve maximum re-usability: the framework is less re-usable because it makes some assumptions about the general architecture of the application, but since the features are also available with a lower-level API – as a toolkit – all text editors and IDEs based on GTK and libgedit-gtksourceview (or even other types of applications) should be able to benefit from the features implemented in libgedit-tepl.
Initially, libgedit-tepl was created as an incubator for new GtkSourceView features, but in practice the features remained in libgedit-tepl, because libgedit-tepl is considered less stable for its APIs, and it's convenient to iterate on the APIs with more freedom. Another reason is that renaming the namespace of all symbols is difficult to do in C.
For the framework part of libgedit-tepl (not the toolkit parts), there is a somewhat clear boundary between libgedit-gtksourceview and libgedit-tepl: the top-level object in libgedit-gtksourceview is the GtkSourceView widget (representing only one view, or one file), while the GtkSourceView widget is at the bottom of the containment hierarchy in the libgedit-tepl framework (it is a “somewhat” clear boundary because there is also TeplBuffer, a subclass of GtkSourceBuffer).
The top-level object in libgedit-tepl is TeplApplication, representing the whole application which can contain several windows, with each window containing one or several GtkSourceView widgets (typically with a Tabbed Document Interface).
So the libgedit-gtksourceview library is not aware that there can be several files opened in the application, while the libgedit-tepl framework has a complete view of the application with regards to the opened files/tabs. It permits to implement higher-level APIs.
The API is now constantly unstable. The library soname is adapted (if needed) for each release.
libgedit-tepl contains experimental APIs, sometimes even unfinished features. API design is hard, it needs an iterative process. Instead of being stuck for years with a non-optimal API, the libgedit-tepl developers want to be able to break the API at any time, to iteratively improve it. Sometimes we see possible improvements several years later.
The API breaks are documented in this section.