Re: Developing a new text editor widget?

[Rena <hyperhacker gmail com>]

On Sun, Jun 5, 2016 at 1:35 PM, Sébastien Wilmet <swilmet gnome org> wrote:

Hi,

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

Christian talked a bit about it here:
https://mail.gnome.org/archives/gtk-devel-list/2016-March/msg00037.html

Which is inspired by this paper:
https://www.cs.unm.edu/~crowley/papers/sds.pdf
"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.

Cheers,
Sébastien
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

As an application developer, my main gripes with GtkTextView have been:

1. The view/buffer model. I expected that the view just asks the buffer for text, and I could supply a custom buffer object that generates text on the fly. In reality it seems I have to use a GtkTextBuffer and fill it with the text I want to display, and manually respond to cursor movements by modifying the buffer. It rather defeats the purpose of having a view/buffer model at all.

2. Difficult to compute how much text will actually fit in the view, when varying character sizes (especially heights) are involved. This relates to #1, since I'm not putting text into a view, I'm putting it into a buffer which doesn't know much about how the view is going to render it. This makes it difficult to know how much text I need to supply. (I can usually get away with over-estimating and supplying more than enough, but then when the cursor is moved down at the bottom of the view, it wants to scroll, so I have to handle that... also I hadn't even thought until now about what "select all, copy" will do in this case.)

3. No way to control the positioning of text and/or movement of the cursor. When implementing a hex editor widget, I wanted to display data in a format like "00000000__00_00_00_00__00..." (where _ is a space), but have the cursor skip over the spaces. I could find no way to achieve this except by (again) manually handling all cursor movement events, trying to figure out what the best valid position is for where it's trying to go, and putting it there. I had hoped I could either tag the spaces to say "have the cursor skip over this", or add a "margin-right" attribute to the digits like I would in a web page, so that spaces would be added without using an actual space character. (Although in the latter case I'd have to have a custom "copy" handler that renders the text *with* spaces for the clipboard, so that might not be so good either.)

--

Sent from my Game Boy.