Re: [gedit-list] gtide - gedit to IDEs (and beyond)

[Sébastien Wilmet <swilmet gnome org>]

Some more reflections.

On Mon, Mar 28, 2016 at 07:51:24PM +0200, Sébastien Wilmet wrote:
> On Mon, Mar 28, 2016 at 06:31:52PM +0200, Paolo Borelli wrote:
> > The fact that we have to come up with cool names for the library itself, is
> > a hint that the library does not have a well defined role.
>
> It has a well defined role. Creating a text editor framework.
> GtkSourceView is aware of only one view, one file. The framework would
> handle multiple views, i.e. it would be an MDI framework (for text
> editors). So there is a clear boundary.

A better name for the library would be "GNOME Text Editor Framework", or
Gtef. But Gtef is a really ugly name in my opinion.

Not all library names have a serious name. It doesn't mean that they
don't have a well defined role. For example Enchant, GNU, projects named
in relation to its creator (Linux, Git), etc.

I must note that you didn't like the name "gspell" either…

Anyway, let's not bikeshed on the name.

> Sorry if it was not clear. I have a clear idea of how the framework
> would be designed (not in the details, but the general architecture).
> It's not a new idea, I thought about it already five years ago, so I
> will not repeat myself:
> https://mail.gnome.org/archives/gedit-list/2011-January/msg00055.html
>
> In short, what would you do if you wanted to create a new text editor,
> with a Multiple Document Interface (MDI) and based on GtkSourceView? You
> would need to rewrite almost all of the gedit core codebase if you want
> to have a decent text editor. A fork is not a good solution, because you
> would need to maintain two times 40k lines of code…
>
> So, in those situations, a better idea is to write a library. And, even
> better, a framework. A framework is more than a library, like explained
> in the above link. And a framework doesn't need to provide necessarily
> an implementation for everything. For example the UI of GeditWindow is
> of course not re-usable. But there would be a GtideWindow class that
> provides at least a useful interface, but I'm sure lots of things could
> be implemented in GtideWindow, like some GActions. An application would
> just need to fill the gaps: implement some vfuncs, assemble the UI, bind
> some GSettings to some properties, add a preferences dialog, and other
> *small* glue code.

To describe in more details the plans for the MDI text editor framework
based on GtkSourceView, the idea is to:
- Take the general architecture of the gedit core, i.e. the classes
  present in the following diagram:
  https://people.gnome.org/~icq/gedit-simple.png
  (for the sake of the argument, let's imagine that the diagram is
  up-to-date)
- Make that OOP design re-usable, by creating a framework on which other
  text editors can base their code architecture upon.
- To be more useful, the framework can also provide an implementation
  for some features, not just interfaces.

That's the general goal.

Now, how to go from the current gedit codebase to that framework, there
are several solutions. But the plugin system of gedit complicates
dramatically the problem. If there was no gedit plugins, no API, the
gedit codebase could be refactored at will, creating the framework
incrementally, class after class.

So, the perfect solution would be:
1) Keep the gedit API as-is, so the plugins don't need to be ported.
2) Refactor the code incrementally to move the re-usable code to a
   shared library, so it can be used by other text editors.
3) Be able to change the API of the framework freely, because creating a
   framework is a difficult task, it's difficult to get the API right the
   first time (and gedit is currently not perfect).
4) A solution that doesn't take ages to accomplish.
5) Not by forking gedit, because maintenance would be duplicated, at
   least temporarily.

For 2) and 3), there is a simple solution: when an API break is needed,
bump the major library version so it's parallel installable with
previous major versions. With a build system where the API version is
not hardcoded everywhere, this is simple to do. See for example the
build system of gspell:
https://git.gnome.org/browse/gspell/tree/configure.ac?id=78c3d417f5a0fb827213f0353386209090658ea5#n43

For achieving 4) and 5), 1) is required, because if plugins need to be
ported to new APIs, it would take way more time.

The tricky part is of course 1), not breaking plugins. Although creating
a framework is itself not an easy task either. So the two together…

Does a perfect solution exist? Or are there conflicting goals? How would
you approach the problem?

To be honest I'm tempted to fork gedit, remove the plugin system, to
have more degrees of freedom to create the framework. The fork of gedit
would be called for example gnotepad, since it would be a streamlined
version of gedit. And for gnotepad I could create the UI that I want
(since I disagree on several points about the current gedit UI).

Or, there is maybe a better practical solution than forking gedit. The
gedit API for plugins could be changed as a set of interfaces. The Gedit
namespace would be used only for those public interfaces. The rest of
the code would need to have another namespace. As long as the interfaces
are still implemented correctly, the plugins would work fine. Then the
codebase with the new namespace can be refactored to create the
framework. The framework would have yet another namespace, of course.

Or the framework could actually have the Gedit namespace, providing the
set of interfaces for plugins. But in this case the initial set of
interfaces must be kept backward compatible, otherwise plugins will
break. So it conflicts with point 3).

Do you see other solutions? (apart from abandoning the idea of the
framework altogether).

And I think keeping the gedit plugin API backward compatible is an
illusionary goal, since for gedit 3 the API has been broken three times
already. So it conflicts with 4). And the solution might be forking
gedit.

And this is almost pure theoretical. And like someone said "The
difference between theory and practice tends to be very small in theory,
but in practice it is very large indeed."

So if I want to do something about it, I need to try a solution and see
how it goes.

--
Sébastien