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



Hi Sébastien,

    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.
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) and having an external library with a stable API and ABI can get in the way of refactorings and incremental changes.

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.

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.


Ciao,

     Paolo






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



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