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

[Sébastien Wilmet]

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.

> 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?

> & multi threaded architecture.

Ok, this one is not possible with GtkTextView.

> Furthermore we need a text representation for non gui
> cases that supports line/columns.

GtkTextBuffer can be used without GUI.

> 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 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.

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.

And some developers enjoy writing C code. Apart from the manual memory
handling, it is a nice language, with a really good toolchain.

--
Sébastien