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

On Mon, Mar 28, 2016 at 06:31:52PM +0200, Paolo Borelli wrote:
    honestly I am not so convinced about adding yet another library.

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.

If we have generic widgets they belong in gtk, if we have code editing
utils they belong in gtksourceview, all the rest should be "glue" code
specific to an application current UI design (gedit in this case)

40k lines of code is a lot for just "glue" code in gedit… I agree some
widgets in gedit are generic and could move to the libgd for example
(the print preview for example).

having an external library with a stable API and ABI can get in the way of
refactorings and incremental changes.

That's why I explained that we can bump the major version of gtide and
break the API every 6 months if we want. Other text editors can still
use older versions of gtide that way, and can do the port at a different
time than the GNOME schedule.

Even for plugin developers would be confusing: today it is already pretty
bad that a plugin developer should keep asking himself:

"Ok I need this method to operate on the text file, where do I look? I
guess in the GeditDocument documentation... uh, no... uhm, maybe in
GtkSourceBuffer? Nope, nothing... ah, ok, found it, it is in GtkTextBuffer".

Splitting things in yet another small lib with its own namespace etc would
make things worse.

When the framework is finished, it would be gtide plugins, not gedit
plugins. All the API would be in gtide and below.

Of course I know reality is not so black and white and I completely agree
with your goal of making code reusable, so I apologize in advance if I
sound too negative. My suggestion is to not focus yet on API stability and
on the library infrastructure and to not spend time porting plugins, but
instead first discover what would go in the library and then we can discuss
together where it belongs and how to share it.

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:

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.


On Mon, Mar 28, 2016 at 5:52 PM, Sébastien Wilmet <swilmet gnome org> wrote:


I'm creating a new library called gtide, currently hosted on GitHub:

It's to continue making the gedit source code more re-usable. The goal
of gtide is to create an MDI text editor framework:

gtide would be a public API for gedit and gedit plugins. When moving
some code from gedit to gtide, the code in gedit would be removed and
the plugins need to use the gtide API instead.

The other solution is trying to keep the gedit API as-is and writing
proxy methods or an adapter. But it gets in the way:
- the API docs need to be duplicated (well anyway it's almost
  non-existent in gedit).
- it's a lot of code to keep in gedit.
- other annoyances, like: for functions taking a variable number of
  parameters, the proxy is a bit more complicated to write.

So I think putting the re-usable code in a shared library is the best
thing to do. That way it can be used directly in other text editors as

When an API break is needed in gtide, we can bump the major version so
it's parallel installable with previous major versions. And that, every
6 months if needed. Who cares if we end up with gtide-17?

About the name, gtide, "edit" in "gedit" has been reversed. It can also
be seen as an acronym for "gedit to IDEs", which is the goal, easing the
creation of new text editors and IDEs. And this could create a "tide" in
the text editors field :) I prefer "gtide" than "gcode" (gcode was the
other name coming to my mind). For me, gedit is not about code, quite
the contrary, I use gedit only for non-programming text editing tasks. A
notepad-like. I guess the Microsoft employees who developed notepad
didn't use notepad to develop it. The same for me and gedit. So it makes
sense. Also, pronouncing "gtide" is more beautiful than "gcode", in my
opinion. And another reason is that there will maybe be a GtkCodeView in
the future, replacing GtkTextView/GtkSourceView.

So, creating gtide, porting the plugins to the gtide API etc, is quite a
bold move for gedit. But such a bold move is needed. The new library
needs to have a different namespace. And it needs to be different than
GtkSource, since the GtkSourceView repo is not suitable to develop a
framework where API breaks will probably be needed.

What do you think?

gedit-list mailing list
gedit-list gnome org

gedit-list mailing list
gedit-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]