On Mon, Jul 1, 2013 at 1:02 PM, Ville M. Vainio <[email protected]> wrote:
> I'm not sure interrupting the coloring is an important use case. If we start coloring "lazily" (i.e. 0.5 - 1 sec after entering the node, users should not be massively bothered by it). Thanks for your comments. I have been revising my opinions as I write this :-) For reference, rev 5818 adds leo/core/qsyntaxhighlighter.py as a study aid. It is supposed to be equivalent to the actual QSyntaxHighlighter (QSH) class, except that the statements "ranges << r" are commented out. I just verified that the QList class defines the << operator as a list append. I'll fix this soon. The all-python code uses only a single class, containing all the methods of the QSyntaxHighlighterPrivate (QSHP) class. This is a simpler and more Pythonic way, imo. It doubt that delaying coloring will increase performance or responsiveness sufficiently. See the discussion below about QTimer.singleShot. > Rewriting C++ code in python is probably a bad idea performancewise. I agree. The obvious thing to do would be to create a subclass of QSH that changes as little as possible. In particular, we would like to leave the methods of the QSHP class as C++ code. QSH.rehighlight calls QSHP.rehighlight, which in turn calls the other private QSHP methods, so there seems to be a way to call these private methods. However, the all-python class will be useful for experimentation. If nothing else, it provides a basis for detailed traces. Furthermore, I would like to create a framework in which performance doesn't matter so much. The idea is to allow incoming events to interrupt coloring. This would maximize *responsiveness* in exchange for a small increase in total coloring time. Yes, this may be difficult. Finally, the detailed study I have done of the code has been useful. For example, the QSH ctor calls QSH.setDocument. This is a bit clumsy, because it queues up a recolor using QTimer.singleShot. The workaround would be to connect a dummy document to the QTextEdit passed into QSH. Since the first coloring is *already* delayed in QSH, I don't think we can rely on any other delay to solve the performance problems. In short, these are very early days. I plan to use the all-python code for study, but if debugging the new code (especially _applyFormatChanges) becomes difficult I may incorporate an instance of QSH as a helper. In any case, there are lots of experiments to run, and lots of open questions to resolve. Only then can I make any kind of assessment about speed. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
