Currently, leo uses getAllText to access the text in a document. All of the text is not what leo NEEDS, it just uses it because python string handling is convenient and standard.
The problem with this approach is that it doesn't scale. I tried solving it by caching, but it leaves something to be desired - namely, if there were changes in QTextEdit that were out of control (e.g. a qt specific plugin could bypass leo in text manipulation and neglect calling invalidateCache). I still think caching is the quickest path to high performance, but it seems to be case that it's less important to reach a solution quickly and more important to always have access to "concrete" contents of the widget, with no middleman that can screw things up. The answer, I think, is QTextCursor with help from QTextBlock to access the data: http://doc.trolltech.com/4.4/qtextcursor.htm http://doc.trolltech.com/4.4/qtextblock.html Currently, I think, leo is "fighting" QTextEdit by not using the direct native way of dealing with the contents. This may look attractive on paper, but kills the performance with large data. We should find all the operations on text insert path (just your old single character entry) and optimize away the places that do getAllText. This can be done by creating more granular operations like "getLine()" in gui side, and implementing the tk version in current way (getAllText and string operations), while doing the qt equivalents with proper QTextCursor/QTextBlock operations. It should also be possible to implement colorization with these classes. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
