The GSoC on GtkSourceView/gedit comes to an end

The first part took a little longer than expected. But I’m happy with the results, the search and replace API is simple and flexible, there were not a lot of bugs to fix, and gedit users will be happy with the improvements (including the regex search).

I’ve changed a little what was initially planned for the second part of the GSoC. Ideally, it was to rework the color schemes to use CSS, and investigate GtkTextTag to modernize it. For the color schemes, it was not really a high-priority issue for GtkSourceView, writing them in XML works fine. And the GtkTextTag investigation would have been the logical follow-up. But with the remaining time, I have found other interesting and smaller tasks instead.

The past few weeks I worked on various things in other parts of GtkSourceView and gedit: better document the API, fix some bugs, improve the code here and there, and investigate two longer projects: the code folding and making the gedit source code more reusable.

I’ve written a utility class to navigate quickly through a set of GtkTextMarks. It is a cleaner implementation of GtkSourceMarks, and it will be useful for the code folding.

Making the gedit source code more reusable

For making the gedit source code more reusable, I’ve created a git submodule called libgedit. Like the libgd, the API/ABI stability is not guaranteed. The purpose is to try to move as most code as possible in the libgedit, iterate the API if needed until it is good enough to be included in GtkSourceView. So the libgedit would be a staging area between gedit and GtkSourceView. There is a problem though: gedit has an API for its plugins. And if possible, it’s better to not break the plugins… If the code moves from gedit to the libgedit, and then from the libgedit to GtkSourceView, there can be several API breaks. On the other hand, if the code goes directly in GtkSourceView, there is at most one API break (that can be avoided if the gedit functions are simply deprecated, not removed). With the second solution, the risk is to discover problems too late.

Maintaining the gedit plugins API in the libgedit is one problem. There are other problems: it would be nice to share the translations; have an API documentation only for the libgedit (with GTK-Doc, I mean); working with a git submodule is less convenient; having the same namespace (“Gedit”) for gedit and libgedit is a problem when trying to make the code more reusable; a headers nightmare, some headers are private, others are public, and others are split between gedit and libgedit; and so on.

So I think it will be simpler to move the code directly to GtkSourceView. The API must be well thought. The developers must have enough time during the 6-months development cycle to iterate the API if needed. And ideally the API must be tested on other applications than gedit. If it is done slowly but surely, by small steps every cycle, it should be doable.

That’s all folks. Thanks to Ignacio Casal Quinteiro (nacho) and Paolo Borelli (pbor) for their reviews, advices and (sometimes late ;-) ) testing. Thanks to Garrett Regier (gregier) for having well tested the new search and replace in gedit. And thanks to Google and GNOME, for accepting me as a GSoC student.