Re: A prototype of fast Qt tree drawing

I am glad that you started to work on this issue. Your recent posts in other thread have opened my eyes and I was planing to encourage you to go and do this issue yourself in your own way. In our previous discussions and disagreements I misjudge you. I was at some points annoyed by your

A prototype of fast Qt tree drawing

The new code is mostly in qtree.partialDraw, in the "quick-draw" branch. The new code is a prototype of #942 . I do *not* plan much more work on it. I just wanted to explore some ideas to so I could stop thinking about them. The code draws

Re: About unit testing Leo

On Wed, Aug 8, 2018 at 7:56 AM, Terry Brown wrote: > I see plugin load time and settings processing as separate issues, so not really sure how these two relate... They don't. This discussion has grown way beyond unit testing. The main point is that caching settings has no chance. Edward --

Re: About unit testing Leo

On Wed, 8 Aug 2018 01:15:04 -0700 (PDT) "Edward K. Ream" wrote: > On Monday, August 6, 2018 at 9:34:56 PM UTC-5, Terry Brown wrote: > > There may be existing personal plugins that would break if plugins > were > > loaded after the outline was fully loaded, but then again it's > > possible to

Please help with #672: travis-ci

#672 suggests that Leo should use Travis CI. One would think that this would be easy, considering how many projects supposedly use Travis CI. However, I have found the setup process mysterious. I would appreciate

Re: About unit testing Leo

On Wednesday, August 8, 2018 at 3:15:05 AM UTC-5, Edward K. Ream wrote: Alas, saving settings (no matter where), is a form of caching! This is a > fatal flaw, because there is no guarantee that the *present* settings > files are in the cache. For example, the cache won't contain >

Re: About unit testing Leo

On Monday, August 6, 2018 at 9:34:56 PM UTC-5, Terry Brown wrote: There may be existing personal plugins that would break if plugins were > loaded after the outline was fully loaded, but then again it's possible > to devise code that breaks in response to any change in Leo, it's > impossible