On Tue, Feb 17, 2009 at 9:49 AM, Ville M. Vainio <[email protected]> wrote:
> > 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. I agree completely. > > 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 Leo already uses QTextCursor. For example: Text widget classes--> class leoQTextEditWidget-->Widget-specific overrides (QTextEdit)-->hasSelection So, if I understand you correctly, in getAllText you would replace:: s = w.toPlainText() with:: s = w.textBlock().text() But I see no QTextEdit.textBlock method. How do we get the QTextBlock? > 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. I didn't know there was any other way. I'd be happy to try alternatives. This should be a clean solution. > We should find all the operations on text insert path (just your old > single character entry) and optimize away the places that do > getAllText. I agree. Some parts of the optimization can be done by passing around an 'allText' keyword param. Other parts may require changes like your next suggestion. 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. We'll have to see what larger chunks would make a difference to the important code. w.getLineAtCursor and w.getLineAtMark seem reasonable. As we have discussed before, cursor operations are a prime candidate for this kind of optimization. Indeed, the lack of w.moveCursorUp, w.moveCursorDown, etc. seems like a long-unnoticed hole. Ah Gee, Ville. This really is too much fun :-) I may have to fix this before other bugs :-) Edward --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
