Developing a new text editor widget?
- Date: Sun, 5 Jun 2016 19:35:58 +0200
- From: Sébastien Wilmet <swilmet@xxxxxxxxx>
- Subject: Developing a new text editor widget?
I'm not going to the GTK+ hackfest, but there is one subject listed on
the wiki page that I want to talk about: textview/sourceview
Christian talked a bit about it here:
Which is inspired by this paper:
"Data Structures for Text Sequences"
It would indeed be really nice to have such an implementation, to
support very large files and very long lines (GtkTextView currently
doesn't support well very long lines, there is a performance issue). But
writing a new text widget is a major undertaking. For example, just for
the mmap idea, is it possible to mmap a remote file? (that's a real
question, I actually have never tried). And what about encoding
conversion if the file isn't UTF-8?
There was also some talks about a monospace-only textview. But even in
source code, a string or comment can contain text in any language. So
having good i18n support as an option can be a big advantage when
choosing a text widget or toolkit.
For source code, GtkTextView is really not that bad IMHO. Normally
source code doesn't trigger the very long line problem (and even, this
problem in GtkTextView is fixable by internal refactorings, although
nobody tried recently AFAIK). And source code is contained only in very
small files, it is not a problem to load e.g. 20k lines in memory.
And if a new text widget is written, there is the question about the
API. If the API is different, porting all the applications to it would
also be a huge amount of work. The GtkTextView API is not that bad, I
find it convenient to use, even if it could be modernized or improved
here and there (leverage CSS, better support multiple views, and a few
smaller things). So, if one day a new text widget is written, I think it
would be a good idea to not diverge too much from the GtkTextView API.
That's all, I wanted to share my thoughts.
gtk-devel-list mailing list