The approach i suggested early on was letting QTextEdit handle stuff that is now handled in leoEditCommands. This would kill lots of code that could be considered redundant
On 10/10/11 6:22 PM Edward K. Ream wrote: Almost from day one, Leo has defined gui base classes in the core, and subclasses in gui plugins. I plan to continue that organization, but I would like to remove some of the wrapping layers if possible. The present scheme has one or two too many redirection layers, and they are more of a nuisance than a help. One idea would be to define **interface classes** that define the desired api's. As in Zope. Unit tests could test that subclass implements the interface class, without having to resort to quite as much error-prone machinery as at present. **Important**: I don't anticipate changing the api itself: that would require a thorough rewrite of Leo's core. That would be worse than pointless: it would be error prone and give no gain whatsoever. Your comments please. 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. -- 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.
