Making the gedit source code more re-usable

Implementing a text editor on top of the GtkSourceView library is currently a lot of work. Creating a specialized text editor should be easier. Instead of re-inventing the wheel, it is better to make the gedit source code more re-usable.

Where to put the re-usable code?

Depending on the feature, the re-usable code can be moved to:

• GtkSourceView or Tepl

• a new library (with a stable or unstable API)
• a git submodule
• another directory in the gedit repository

Search and Replace backend

The first step was the search and replace. For a GSoC, a new and more flexible API has been created in GtkSourceView, the regex search has been implemented, and the API in GeditDocument has been deprecated (and then removed several releases later).

File Loading and Saving backend

Another step was the file loading and saving. It is like the search and replace: a new and more flexible API has been created in GtkSourceView, some of the GeditDocument API has been removed, and some functions have been deprecated.

Spell-Checking

Another step was the spell-checking. The spell-checking is implemented as a plugin in gedit, so making the code re-usable was easier, there is no need to care about API breaks as is the case for the gedit core. The plugin code could be refactored freely. A new library called gspell has been created, initially with an unstable API, but gspell has now a stable API.

Tepl - Text editor product line

See the thoughts about a Tabbed Document Interface framework for GtkSourceView. To implement this idea, the Tepl library has been created.

Some of the Tepl code comes from gedit, but a lot of new code is written as well.

gedit is incrementally ported to Tepl, and Tepl is developed alongside gedit, with all the official plugins ported to the new gedit API. It is sometimes unavoidable to break the gedit plugin API, so third-party plugins will need to be ported independently.

Why?

gedit is a general-purpose text editor with a plugin system, so plugins can be created instead of creating specialized text editors (or creating other general-purpose text editors). I (SébastienWilmet) think that a specialized text editor is easier to use and has a potentially better usability. Of course, a general-purpose text editor is still needed for the languages not covered by specialized text editors.

A specialized application should ideally Just Work, and have a simple configuration. A specialized application can be better at what it does since, by definition, it is specialized for that task.

The gedit UI is generic so it suits most plugins. But some plugins may have special needs, so the gedit UI may be too restrictive in some cases. Thus, a gedit plugin is suitable for a small plugin. If you want to transform gedit into a complete IDE, it will be more difficult. Also, a user generally wants to perform several tasks at the same time. For example working on a C project and writing a LaTeX report. If two big gedit plugins for C and LaTeX must be enabled at the same time, gedit would probably become bloated. And if you want different text editor settings for C and LaTeX (like the indentation style), it becomes also more complicated. Or having different UI states for the different tasks is currently not possible with gedit.

This could be fixed partly with a profile feature: launch a gedit instance with the C profile, and launch a different gedit instance with the LaTeX profile. (see the roadmap if you are interested to implement this, and see also this mail).

But even if gedit has profiles, a specialized application has other advantages:

• The UI can be exactly what is needed, it is neither too generic nor too restrictive. Example of a too generic UI in gedit: the tabs in the bottom panel: if you have only one possible item in the bottom panel, the tab is useless. Example of a too restrictive UI in gedit: if you want a right-side panel, or if you want to use the more flexible GDL library.

• You are free to implement a completely different UI design for your application. For example if you want a traditional menubar and toolbar instead of an headerbar.
• Some gedit features are not useful in a specialized text editor: for example it is useless to print the LaTeX sources, what is needed is to print the generated PDF with evince; another example is the list of languages for the syntax highlighting, if your application is specialized for only one language, it is not needed to be able to choose another language.
• The features can be more well integrated so the application forms a coherent whole. For example an integrated file browser can have an option to hide the auxiliary "build files" generated by the compiler of your specific language.

Anjuta

If you want to create a specialized text editor, another solution is to reuse the Anjuta source code.

According to the Anjuta developers, the Anjuta source code is more reusable. But:

• Under the hood, GtkSourceView or Scintilla can be used. Anjuta makes an abstraction to be able to use the two libraries, so it adds more complexity. From the gedit point of view, it is better to enhance GtkSourceView and use only this one, since it is more well integrated to GNOME.

• The GDL library is used. For small text editors it is not really useful.
• Currently the gedit plugins and Anjuta plugins are incompatible. Anjuta doesn't use libpeas for its plugin system. The Anjuta plugin system is more sophisticated, so libpeas have to be improved to be able to use it in Anjuta.

  • (SebastienGranjoux) The main issue is not the plugin format but that plugins interact with each other only though interfaces. No plugin access directly the GtkSourceView or GtkTextView object. It adds some complexity in Anjuta and limit the possibilities of plugins but they should be a bit easier to write and less sensitive to changes.