Developing a new text editor widget?
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
Re: Developing a new text editor widget?
On Sun, Jun 5, 2016 at 1:35 PM, Sébastien Wilmet 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 "__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
Re: Developing a new text editor widget?
On 06/05/2016 10:35 AM, Sébastien Wilmet wrote: > 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? You wouldn't want to mmap() the whole file, because that would still limit how large of a file you can open on 32-bit systems. You would want mapping windows with a page replacement strategy. Once you get this far, mmap() is simply an optimization over a page/extent read. You need to iconv/etc the whole thing sequentially and therefore must read in the whole file upfront. However, you can do this and then proceed as normal with the alternate file afterwards (using O_TMPFILE or tmpfs backed fd). > 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. Are there situations where the character is larger than a single cell? Do we want to support widgets interleaved with characters? I know I'd like widgets *between* lines, but not sure I want widgets between characters/words on a line. LTR/RTL is one thing, but that can still exist while being monospace. The important performance gain we want is to make the operation of converting line,column → x,y as close to O(1) as possible. We likely still need an index for line positioning though, because I'd like to be able to insert widgets in-between lines. (Imagine showing IDE fixits as a list of items underneath the line they fix). We definitely want both an line and a column index going forward though. > 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. There are a few things that it is really bad at. You have to scan linearly from O..n to determine line height. There are all sorts of hacks to do this upfront in high-priority idles. It's why I still can't open a file, and scroll to a line number like 1000 correctly without retrying a bunch of times. If we could sacrifice 100% correct scrollbar correctness (really, its not that big of a deal) we could avoid this problem. Just estimate by byte offset the Y position, and make calculated offsets in the Y position b-tree/treap/index relative to it's parent node. > 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. Mostly agree, but I wouldn't be willing to lock myself into an API choice until the problem is solved. As you said at the start, this is a massive undertaking. While I have ideas on how to implement this, I need to be realistic with my time and I have a lot of work in front of me right now. The main thing I'd like to learn at the hackfest is what constraints must we take on to do fast text scrolling with GSK+(GL/Vulkan/etc). This pixelcache copying on every frame is really hard to optimize. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Developing a new text editor widget?
On 05.06.2016 22:33, Christian Hergert wrote: > On 06/05/2016 10:35 AM, Sébastien Wilmet wrote: >> 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. > > There are a few things that it is really bad at. > > You have to scan linearly from O..n to determine line height. There are > all sorts of hacks to do this upfront in high-priority idles. It's why I > still can't open a file, and scroll to a line number like 1000 correctly > without retrying a bunch of times. > > If we could sacrifice 100% correct scrollbar correctness (really, its > not that big of a deal) we could avoid this problem. Just estimate by > byte offset the Y position, and make calculated offsets in the Y > position b-tree/treap/index relative to it's parent node. That could be an interesting feature. Places with dense code (many characters, compared to the number of '\n's) will take longer to scroll through (if each PageDown scrolls N bytes). -- O< ascii ribbon - stop html email! - www.asciiribbon.org signature.asc Description: OpenPGP digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Developing a new text editor widget?
On 06/05/2016 01:25 PM, LRN wrote: >> If we could sacrifice 100% correct scrollbar correctness (really, >> its >>> not that big of a deal) we could avoid this problem. Just >>> estimate by byte offset the Y position, and make calculated >>> offsets in the Y position b-tree/treap/index relative to it's >>> parent node. > That could be an interesting feature. Places with dense code (many > characters, compared to the number of '\n's) will take longer to > scroll through (if each PageDown scrolls N bytes). That should be fine. The issue is more about when you jump to 75% of the document from the top. We can calculate local sizing information while skipping the line-height calculation of 0..75%. -- Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
