Re: [gedit-list] libgedit, again

[Sébastien Wilmet <swilmet gnome org>]

Hi Paolo,

Thanks for your reply.

On Sun, May 03, 2015 at 08:15:32PM +0200, Paolo Borelli wrote:
>      in principle I surely agree with the goal of making the code
> reusable and factoring out code to be used in latexila and other
> projects.
>
> About the approach of creating a "gcode" library: I honestly do not
> know. It is very hard to say on advance if it will be the right
> approach or not: my general feeling is that at the end of the day each
> application has to implement its own "glue" code to make things work
> together, and the best thing to do is to share the best ideas and
> principles even at the cost of some cut&paste code.

The approach would be:
1. Take one class at the bottom of the containment hierarchy.
2. Be sure that that class doesn't depend on classes higher in the
hierarchy (e.g. in GeditTab, do not depend on GeditApp).
3. Make that code reusable by moving it to gcode, and keeping the
gedit-specific stuff in gedit.

> For instance at a quick glance at your branch, I am not so convinced
> about sharing "gedit-debug" (which is a bit dated and could probably
> be accomplished in more modern ways and which needs anyway application
> specific env vars)

gcode-debug would be internal to gcode, apps would not use it. I've
looked at the GLib API for more modern debugging functions, namely
g_debug(), but it doesn't support enabling only specific sections with
env variables. So an idea would be to make a debug utility that
registers a list of sections and see if those sections are enabled,
without hardcoding the list of sections. So that gcode-debug and
gedit-debug can use that utility to registers the sections for gcode and
for gedit or another app. But this can be done later.

> or gedit-utils (I would like to see most of that
> code go away).

Yes I think lots of utils functions are not used anymore in the gedit
core, but they are still there because they are public, maybe some
plugins still use them. This is another thing that can be done later, to
deprecate some of the functions and keeping them only in gedit, not
gcode.

> Anything that deals with settings also needs to be app
> specific and the same goes for things that need application-specific
> css (removing some borders etc).

Yes, properties can be created, and the app just needs to bind the
settings. For CSS, it depends, the close button for example is useless
without the CSS.

> How much is it left to share? I really do not know...

Ideally it would be nice to create a text editor like gedit in 1000
lines of code (without the plugin system). Just the code for the UI,
mainly for the main window and the preferences dialog. That cannot
really be shared.

I think there is a lot of code that can be shared. Maybe 80% of the
code.

And the idea is also to create the framework, that is, provide a good
code architecture to create a text editor on top of GSV. Other text
editors can already look at the gedit code architecture, but if an
implementation is also reusable, it's easier.

> if there are
> things we can move down in gsv, we should at least aim for that in the
> long term.

Yes, that's the goal in the long term. But in GSV we don't really have a
way to provide unstable APIs.

Another reason is to rename the classes without the need to fix the
indentation everywhere. With gcode, that's the same length as gedit so
the renaming is trivial.

> If there are some more-or-less generic widgets, we could
> take an approach similar to libgd/libegg.

With the git submodule, there was the problem with translations and
API documentation. By having the code in the gcode directory, it's
easier.

When the MDI framework is stable, we can move the code to a real
library, be it GSV or a new one.

> Another downside of splitting out a separate .so is that makes things
> a little more complex for win32 port (this is surely fixable, but I
> thought I'd at least mention it).

No, it's not a separate .so, it's a separate .la. It's not a shared
library, it's a libtool library that is statically linked with gedit. Is
it a problem for the win32 port?

> To sum it up: do I agree with your effort? yes. Do I agree with the
> gcode approach: maybe, I am afraid that we'll figure out only when
> trying, but my suggestion would be to start small.

Yeah, creating the gcode directory in the gedit repo is quite a big
change for the code organization.

When a class needs to be split in two, to create a new one in the
inheritance hierarchy, it is technically possible to keep the same
namespace, and have two different class names. For GeditDocument this is
easy, we can create GeditBuffer. But that's a trick, and finding such
good names is not always possible, and it would be more difficult to
remember which one is reusable and which one is specific to gedit. So
creating a new directory is needed in my opinion, to have a clearer
separation.

Anyway, I can continue the branch to see how it goes with GeditDocument.

For adding more and more classes to gcode, if for each of those classes
there is a subclass in gedit, we'll probably need an abstract factory,
so when gcode needs to create e.g. a tab, it knows that it must create a
GeditTab and not a GcodeTab (for GeditDocument there is already a
factory method in GtkTextView).

Does it sound a good plan?

--
Seb