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

On Tue, Mar 29, 2016 at 10:59:33PM +0200, Paolo Borelli wrote:
On Tue, Mar 29, 2016 at 9:12 PM, Sébastien Wilmet <swilmet gnome org> wrote:
So if I want to do something about it, I need to try a solution and see
how it goes.

Absolutely. I 100% agree and this was my main point in my previous mail.
What I am trying to say is to not worry right now if this is going to be a
library that is going to be called gtide or gtef, do not worry on whether
we should use ABI bumps and make it parallel installable, do not worry
about porting gedit plugins, do not worry about porting gedit at all and do
not worry about forking gedit under the name gnotepad.

But all that list of things that I should not worry about is exactly
some practical stuff that will need to be handled at some point.

From time to time, I like to head out of the water and look around me,
see in which direction I'm actually heading to, look at the horizon and
take the time for some reflections to see if navigating with a snorkel
is actually the best way to reach that nearest island.

Just try to factor out the code you want to factor out and once we have a
better idea of what it contains we can discuss about the next steps. Once
you have a prototype, my suggestion would be: 1) try to make a proof of
concept gnotepad (not a gedit fork, just a proof of concept mininal editor
that uses the lib) 2) try to port the gedit core (no plugins) 3) try to
port some other app (latexila, csvedit etc).

Once that is done we will have more clear ideas on how to move forward.

In gedit, the top level class is GeditApp, and at the bottom of the
containment hierarchy there is GeditDocument. I think we agree that the
best way is to take one feature at the bottom of the containment
hierarchy, and make it reusable.

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

So, I can dive in the GeditTab code again and factor out some reusable
code. Then we can figure out where to put it so I can use it in


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