On Sun, Jun 5, 2016 at 1:35 PM, Sébastien Wilmet <swil...@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.
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
