QTextDocument stinks

[elcuco]

(moved discussion from http://www.qtcentre.org/forum/f-qt-s...r-qt-8156.html)

True enough. But you won't be able to get rid of it as long as you cling to QTextDocument... This class does a great job rendering rich text but it sucks when it comes to complying with the need of coders : speed, small memory usage, loading big files, highlighting ... That's why I'm working on a new version of QCodeEdit which already offers a working (I did not say "usable" yet!) alternative to QTextDocument and fulfils all the aforementioned requirement. You might also be interested in QScintilla port to Qt 4 but beware it has a really crappy API...

You must be crazy. You little text editor will be able to handle only latin1 and similar charsets. Will you support chinese? Japanese? Arabic? Hebrew? Hindic?

And about QSyntaxHighlighter? That one stinks. I would like to get more integration between QTextDocument and QSyntaxHighlighter. For example, when pressing "QString::" I would like to know in which document-context this string it, since it's in a comment - I do not need to pop-up the code completion code. If text is entered inside #include, I want to know about it to open a completion menu with the available headers.

Re-writing stuff is always fun, but the real question is what do you gain. Sure QTextDocument is slow, but it has a LOT of features. The problem is the highlighters, which not only are a solid-black-box: they are also badly written.

[fullmetalcoder]

You must be crazy. You little text editor will be able to handle only latin1 and similar charsets. Will you support chinese? Japanese? Arabic? Hebrew? Hindic?

I'd just like to point two things out :

• it's not QTextDocument which handles non-Latin1 charsets but QString and QPainter... As I do make use of both I shouldn't loose anything. I admit I've not tried any of those but it should do just fine
• I've not worked on RTL/bidi support but AFAIK it is possible to handle it quite simply through two virtual methods just like done in QTextEdit
• My little text editor is meant to be a CODE editor and AFAIk most programming language use ASCII/Latin1 charsets because they where written in english... As for using other charsets within commets I think this is a bad practice but as I've already said even this should work...

And about QSyntaxHighlighter? That one stinks. I would like to get more integration between QTextDocument and QSyntaxHighlighter. For example, when pressing "QString::" I would like to know in which document-context this string it, since it's in a comment - I do not need to pop-up the code completion code. If text is entered inside #include, I want to know about it to open a completion menu with the available headers.

Re-writing stuff is always fun, but the real question is what do you gain. Sure QTextDocument is slow, but it has a LOT of features. The problem is the highlighters, which not only are a solid-black-box: they are also badly written.

My new document structure comes with a NFA-based (or so I believe I can call it...) generic highlighting engine which actually does a lot more than merely highlighting since it tracks context and parenthesis in a very flexible way. It turns out that a rcc-generated file (1.2Mb) is loaded, highlighted, and usable (user can move scrollbars and type...) within 3 seconds (tests done on a 6 years old PC) whereas the very same file is loaded in twice as much time (I meant PURE loading), takes a dozen seconds to be laid out and then from several seconds to a minute to be highlighted, depending on the algorithms used.
If you are interested you can always check this new framework out (http://edyuk.svn.sf.net/svnroot/edyu...rty/qcodeedit2 ) and see by yourself how well it performs. The cursor-based API is meant to be very close to QTextCursor and the single QDocumentLine class which replace the whole mess of QTextBlock, QTextLine, QTextFrame, ... is equally close to QTextBlock. AFAIK all I may lose is time but that's nothing compared to what I'll gain when it will be fully working...

[elcuco]

the layout (Rtl/Hindic/whatever) is done via QTextCursor. If you are not using it, you are asking for troubles.

[fullmetalcoder]

the layout (Rtl/Hindic/whatever) is done via QTextCursor. If you are not using it, you are asking for troubles.

QTextCursor just walk inside a document. The layout is handled by QTextLayout which generates QTextLine objects filled with data from QTextBlock. Though the draw() methods of QTextdocument and co do not make use of QPainter::drawText() because they can afford using Qt internals I'm pretty sure that there is actually little difference as far as the visual effect is concerned. By doing so the QTextDocument framework may gain some time (and possibly a better look) but I'd be able to do the same if only the Trolls had made the QTextEngine class to public and provided a better interface for exotic rendering. As stated already these exotic charsets are of little use to a code editor and their lack should be scarcely notified but if the Trolls were to acknowledge the fact that a little more flexibility on text rendering is needed then everyone might get happy...

[fullmetalcoder]

the layout (Rtl/Hindic/whatever) is done via QTextCursor. If you are not using it, you are asking for troubles.

After investigating a bit more and having a look at Kate 4 sources it turns out that :

• the layout is definitely handled by QTextLayout which is hopefully available publicly contrary to many other classes involved in text rendering
• QTextCursor itself doesn't know much about these layouts : it just move inside the document and QTextLayout is in charge of painting cursors/selections so as not to mess with these layouts
• using QTextLayout imply some more memory usage and a slower loading/editing but it remains quite decent as far as I tested (both my experiments and Kate )