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

[Sébastien Wilmet <swilmet gnome org>]

On Thu, Mar 31, 2016 at 04:15:27PM +0200, Sébastien Wilmet wrote:
> The next big chunk that I want to make reusable is having a container
> that contains a GtkSourceView plus one or several info bars at the top.
> With a higher-level API to load and save files, that shows an info bar
> in case of error, with options to choose e.g. another encoding etc.
>
> But when I proposed to include a GtkSourceTab container to
> GtkSourceView, you said it was not a good idea to include that in
> GtkSourceView. It could be called GtkSourceViewContainer instead, so it
> is more general and can be used in a different context than with a
> GtkNotebook.

Actually, there is a smaller thing that I want to make re-usable first:
get/set file metadata, with the gedit-metadata-manager on Windows and
GVFS metadata on Linux.

At first I wanted to add the relevant API to GtkSourceFile:
https://bugzilla.gnome.org/show_bug.cgi?id=761138

But I came to the conclusion that gedit-metadata-manager is not good
enough for GtkSourceView:
https://bugzilla.gnome.org/show_bug.cgi?id=761515

GtkSourceView has a stable API. GtkSourceView 3.0 was released five
years ago. Not all of the API is perfect, we discovered some API flaws
too late, and we need to wait GSV 4 to fix the problems. See the bugs
filed with the 4.0 target milestone:
https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=113854&product=gtksourceview&target_milestone=4.0

So, where to put the gedit-metadata-manager and the higher-level API to
get/set metadata? Not in GtkSourceView. If the files are still mixed
with all the other gedit files, the risk is that after some time a
contributor modifies the re-usable files to add a gedit-specific thing
to it (like using GSettings). So a better idea is to move the files to
another directory. But to re-use the code in another text editor, the
code would need to be copied manually and adjust the build system
manually (e.g. to add new dependencies, configure options etc). But it's
not just the code that needs to be copied, it's also the *.po files. A
git submodule doesn't solve the problem of sharing *.po files. So, the
easiest solution, from a text editor developer's point of view, is to
use a shared library.

When using a shared library, it solves all the problems: the code
doesn't need to be copied, the *.po files doesn't need to be copied, the
build system of the text editor needs only a small adjustment, and we
can have a nice API documentation of the library available in Devhelp.

That's why I came to the conclusion that a new shared library *is*
needed. And for that new shared library, we can have a different policy
than GSV and break the API more often (with a major version bump each
time an API break is needed).

So, is it clearer like that?

The new library could be named GTF, not gtide, and I can try to keep the
gedit API for plugins as-is, by using GTF under the hood. But I think
it'll not be possible to do that each time, for example when gedit was
ported to GtkSourceFile, the API of gedit has been broken. And when that
happens, my worry is to port all plugins, especially those in Python.

--
Sébastien