On Fri, 13 Aug 2010 18:17:16 +0300 "Ville M. Vainio" <[email protected]> wrote:
> On Fri, Aug 13, 2010 at 5:57 PM, Terry Brown <[email protected]> wrote: > > > The node appearance tweaking plugin I'd like to find time to write would > > inspect each node and modify aspects of its appearance based on what it > > finds. Inputs would include: > > > > * content of headstring > > * maybe content of bodystring > > * uA attributes of the node > > * prompted by Steve's email below, perhaps depth in the tree and similar > > too > > Hopefully this wouldn't be evaluated on every redraw. I guess I'd try it and see if it was too slow. I believe unnecessary redraws have been largely eliminated? I don't know (lack of familiarity with qt/leo-qt-implementation) whether a lot of "offscreen" nodes are processed by redraw code, that wouldn't help. If it is too slow, then it might be possible to just store the styling for use on each node on each redraw, and only work out the styling for a node when the node's modified. I don't think there's a really good hook for that though, if you want to catch modifications to nodes by scripts writing to p.h. I might be wrong about that though, if p.h is a property with a setter function, it should be hookable. Of course you really only want the hook to fire once after the script's done. Hmm - well, I'll see what the speed's like. On Fri, 13 Aug 2010 18:11:52 +0300 "Ville M. Vainio" <[email protected]> wrote: > IIRC the analysis paralysis was about how to represent the color > thing. You wanted to hard code the colorizing in tree drawing code > (and look up the color from uA), I wanted to keep it more dynamic and > have colorization in a non-core plugin, utilizing the mechanism as in > colorize_headlines.py (that would possibly look at uA). On Fri, 13 Aug 2010 18:17:16 +0300 "Ville M. Vainio" <[email protected]> wrote: > Perhaps a starting point would be a change in tree drawing code that > just user v.color to set the color. Various things around leo would be > able to set colors for vnodes. That wouldn't slow Leo down, and it > would be sufficient to get the classical cleo case where user sets the > colors and they get read/written to from uA's. Ok then :-) So we agree color support should definitely be in the gui core or not in the gui core. I guess I was leaning toward your view (of 18:11:52 ;-) that a plugin could handle it. Cheers -Terry -- 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.
