[MonoDevelop] Why MonoDevelop doesn't use GtkTextView/GtkSourceView?

[Mike Krüger]

Hi
> On Sat, Aug 23, 2014 at 11:47:21AM +0200, Mike Krüger wrote:
>> We used GtkSourceView years ago but we needed more control over the text
>> editor.
>> Things like our incremental like find, folding, support for vs.net like
>> color themes and so on.
> The search and replace is now implemented in GtkSourceView. Some
> GtkTextView-based text editors have the code folding, so it is possible.
> Syntax highlighting and color themes can anyway have a different
> implementation in the application than the one available in
> GtkSourceView.

The search & replace idea was taken from us - therefore it's a bad 
example :).
Code folding is always possible to implement to a degree. But 
implementing like we did would require to change text lay outing (we're 
drawing folding markers as part of the layout) and background drawing - 
see the animations.
It's not a trivial implementation we have. Reworking the gtksourceview 
syntax highlighting, theming, folding, margins and so on would bring us 
very close to an own editor implementation anyways.

GtkSourceView is nice - I do not have complains about that but it 
doesn't solve our problem.

>> As well as our text representation should support snapshotting
> Is snapshotting different than a point in the undo/redo list? Or the
> text buffer saved to a temporary file?
Yes it is because it should be a O(1) operation that brings the whole 
text representation in an immutable state so that it can be used by 
background threads.
>> Furthermore we need a text representation for non gui
>> cases that supports line/columns.
> GtkTextBuffer can be used without GUI.
Relying on a native call for a GetChar slows things down - it's better 
for us to stay on the managed side for getting the best results as a 
.NET application. Each line we have in the .NET world makes our lives 
easier.
For example I can't type with my neo2 keyboard layout in any gtk 
application on windows, on mac gtk was crashing all over the place - and 
still is crashing in many places.

>> Furthermore developing with .NET is much more fun & easier than extending a
>> C component.
> GtkTextView is a quite complex piece of software. GtkSourceView is not
> trivial either. So re-implementing a new text editor framework in C# was
> probably fun, but not really easy. By using GtkSourceView, there is less
> maintenance work for MonoDevelop.
I agree that the editor is a complex piece of software - so is ours. 
Having less maintenance work is a good idea - but there were good 
reasons for us to implement our own editor control. (It wasn't my first 
editor control - I knew what I was up to)

It's even more maintenance work if we would've stuck to GtkSourceView 
because it adds a dependency for us and adds limitations to what can be 
done (like the find animations which required changes to the 
gtksourceview). We've tons of commands that are working differently on 
certain platforms (mac/windows/linux behavior is not the same) - it's 
really hard to implement all that if you give up control.

We've really many features that are hard to implement in a general 
purpose editor  - if it's not supported like our virtual indentation 
spaces. And now it's too late anyways - our text editor is now mature 
enough after 7 years of development.
(And as said - we've been using GtkSourceView before that and felt it 
was too limited for our use case at that time - 7 years ago - I think 
that the GtkSourceView has evolved a lot since then. But atm I don't 
really see any reason for switching back.

Can you give one ? (The maintainance work isn't much right now - most of 
the ongoing editor work is implementing new features or changing old ones)

>> I give the question back:
>> Why didn't the gnome team switch to mono and not why did the mono team
>> choose mono.
> There are millions of lines of code written in C/GObject in GNOME. Take
> only GLib and GTK+ for example. It is not conceivable to rewrite all
> this software in C#/.NET.
It's no need to rewrite all software at once. But the Linux world lost 
14 years of development time and still sticks to C.
AFAIK the GNOME team now wants everyone to write everything in JavaScript ?
> C/GObject is meant to be language-binding-friendly, especially with
> GObject introspection (automatic bindings). If GTK+ is rewritten in C#,
> it would not be possible to use it in other high-level languages like
> Python.
There is IronPython :) - with .NET it's possible to use different 
languages as well. The language problem is just solved at a different level.
> And some developers enjoy writing C code. Apart from the manual memory
> handling, it is a nice language, with a really good toolchain.
That's true. But some don't enjoy writing C - or working with C based APIs.
I for myself hope to never see C again - I think it's a horrible 
language for desktop application development with a bad tool chain 
(begins with the compiler).
But opinions on languages differ - the GNOME team is aware of that :)

Regards
Mike