[gedit-list] libgedit, again

[Sébastien Wilmet <swilmet gnome org>]

Hi,

(With a lack of internet connection I write a mail instead of being on
IRC. But with a mail I can hopefully better explain my ideas.)

So, libgedit. At first I wanted to take one feature, and make it
reusable, for example the file loading and saving (the part still in
gedit, mainly in GeditTab with all the info bars etc). But GeditTab has
lots of dependencies, and with the GtkApplication singleton it's even
worse, for example gedit_app_get_documents() is called in GeditTab,
which is quite bad. A class must know what it contains, but it should
never know who contains it. So gtk_application_get_windows() is
dangerous and can lead to bad code architecture. It means that any class
in an application can call functions from almost any other class, by
walking from GtkApplication, to the main GtkWindow, etc.

So, instead, I think it's simpler to take classes one by one and see if
they are reusable. By starting first at the bottom of the containment
hierarchy. GeditDocument would be a good start and is almost reusable.
There are just some GSettings bindings at object creation (more or
less).

One way to make the code reusable is to put it in GtkSourceView, but it
requires more work. All the gedit API is not perfect, so if it is moved
to GtkSourceView it must be improved first. I'm not against that idea,
but I'm not sure it's a good idea to implement an MDI framework (that's
the long term goal) directly in GtkSourceView with a stable API. A
framework is difficult to do at the first time, so it needs many
refactorings to have something that could have a stable API.

Another idea is to just leave the code in gedit, and apps can copy the
code. With a clear separation between the reusable code and the
gedit-specific code, so that we are sure that the reusable code will
remain reusable (normally), and it's easier for apps to know what code
can be copied. A clear separation can be achieved by moving the classes
to another directory, or moving them to a git submodule. I've tried the
git submodule approach during the end of my GSoC, but it was not
successful, mainly because the same namespace was used. With another
namespace for the reusable code, the separation is even clearer, and we
have more freedom for refactorings. Ideally (1) the gedit API for
plugins must be kept as-is (at least not break it), and (2) the
framework design needs to evolve to improve the API. With the same
namespace that's two conflicting goals. With two separate namespaces,
it's more feasible.

So, do you agree that another namespace is needed for the reusable code?
I have two namespaces in mind: gcode and gtide ("edit" reversed). They
both have the same length as "gedit", which would simplify the renaming
(no need to fix the indentation everywhere). gcode is more meaningful,
although gtide could create a tide in the sea of text editors ;-) (well,
I'm maybe too optimistic…).

So, I'm at a point where GeditDocument could be split into, say,
GcodeDocument and GeditDocument. GeditDocument would be a subclass of
GcodeDocument, and would only keep the gedit-specific parts (GSettings
bindings etc). The gedit API would be kept as-is, with proxy methods or
an adapter to gcode. On the gedit side this would be a lot of
boilerplate, but gcode should not be visible from plugins, it would be
completely internal to gedit.

Another problem with the git submodule was the translations. That's why
I think it's simpler to keep the code in the gedit repository, but in
another directory.

Do you have better ideas? Another idea is to create the MDI framework
separately and port gedit to it when it's finished, with maybe one big
API break for gedit plugins. But I don't really like that idea, because
for the MDI framework I prefer to use the gedit code. So doing the MDI
framework separately would basically be a gedit fork, and all bug fixes
and new features in gedit itself would not be available. So that's why I
prefer changing the code directly in gedit. The only problem is to not
break the plugins at each version.

That's all for today,
Bye,
Seb