[MonoDevelop] Why MonoDevelop doesn't use GtkTextView/GtkSourceView?
swilmet at gnome.org
Sat Aug 23 11:37:43 UTC 2014
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
> 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
> 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
And some developers enjoy writing C code. Apart from the manual memory
handling, it is a nice language, with a really good toolchain.
More information about the Monodevelop-list