On Thu, Oct 30, 2008 at 7:46 PM, Ville M. Vainio <[EMAIL PROTECTED]> wrote:
> - Again, expanding doesn't move the tree so that the focus is at > center of the tree pane (I've fixed this a few times already, it > probably got lost again with some change) I disabled one call to scroll because it seemed to me to be annoying. But maybe I was wrong to do that. This has low priority at present. > - The body pane feels quite a bit slower than the scintilla one. It certainly is. This is likely due to the (partial) syntax coloring. Improving syntax coloring is in the "finally" part of the to-do list. The body pane is good enough at present. > don't have any measurements, and I understand this scenario is still > not optimized. Perhaps the problem is flushing the contents of buffer > to bodyString() too often? At present, setting a color involves creating a selection then specifying the color for that selection. This is likely to be *very* slow, but I don't see an alternative. The to-do list mentions one possible high-level optimization: simulate Tk's list of already-colored ranges, and report that list via the tag_ranges call. There is another optimization that I'll explore tomorrow. It's not on the list. At present the code that sets the cursor gets all text in order to put the request in range. Previously, cursor.setSelection was politely saying that some calls were out of range. Rather than use the QTextEdit method, it may be possible to discover the maximum value using the cursor method. This would be good, as it would result in many fewer strings being allocated. Anyway, all the QTextEdit stuff is just interim scaffolding that will be removed when we switch back to QScintilla. It's plenty good enough for now. OTOH, there will be a lot of work to make QScintilla aware of Leo markup, so I'm making the QTextEdit code as good as it can be. > The first point is trivial to fix, but the second one raises a > configuration issue: > > Perhaps we should have 2 options for body editing: > > - The full-blown leo editing, based on QTextEdit, threading colorizer etc > > - A simpler (but faster) scintilla-based editing mode. It would only > support the lexers available with scintilla, and have the "default" > scintilla editing behaviour. Possibly, only ctrl and alt-based > commands would be passed on to leo core. We have that now: qtGui plugin-->@bool qt-use-scintilla = True We can't actually use QScintilla now because of the byte-offset problems, but that should be fixed with the next Qt release. I think the bottom line is this: I am happily using the qt plugin exclusively for daily development. As a result, the to-do list reflects the items that are urgent (because buggy) or most useful to have. As you can see, the list isn't that long. 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 -~----------~----~----~----~------~----~------~--~---
