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

[Sébastien Wilmet <swilmet gnome org>]

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).

> and
> 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:
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.

--
Sébastien

> On Mon, Mar 28, 2016 at 5:52 PM, Sébastien Wilmet <swilmet gnome org> wrote:
>
> > Hi,
> >
> > I'm creating a new library called gtide, currently hosted on GitHub:
> > https://github.com/swilmet/gtide
> >
> > It's to continue making the gedit source code more re-usable. The goal
> > of gtide is to create an MDI text editor framework:
> > https://wiki.gnome.org/Apps/Gedit/ReusableCode
> > https://wiki.gnome.org/Projects/GtkSourceView/MdiFramework
> >
> > 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
> > well.
> >
> > 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?
> >
> > --
> > Sébastien
> > _______________________________________________
> > gedit-list mailing list
> > gedit-list gnome org
> > https://mail.gnome.org/mailman/listinfo/gedit-list

> _______________________________________________
> gedit-list mailing list
> gedit-list gnome org
> https://mail.gnome.org/mailman/listinfo/gedit-list