[MonoDevelop] Why MonoDevelop doesn't use GtkTextView/GtkSourceView?
mkrueger at xamarin.com
Sat Aug 23 13:41:45 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
The search & replace idea was taken from us - therefore it's a bad
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
>> 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
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.
> 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
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 :)
More information about the Monodevelop-list