On Sat, Aug 10, 2013 at 08:27:26AM -0500, Dick Hollenbeck wrote: > a) If tools are extended from a base class, the persistent behaviours could > be inherited. > > b) If tools are pushed on a stack when they become active, and if you have a > mechanism > which the tool uses to report whether it handled an event or not, then if not > handled you > can pass the event to the next tool on the stack. With this strategy you put > the > persistent behaviours into the baseline tool, and stack temporary other tools > onto the > stack above it. Although you can go to more that two high, this architecture > does not > require that you do.
Both of those are good for me, the second one is a little more complex and in fact emulates at runtime the VTBL (for example in lua virtual calls work *exactly* like that: when a method is not found it get searched in the ancestor class). Do we need dynamic method composition? I.e. will tool A be *always* below tool B or there may be a tool C below tool B? The second scenario rules out inheritance but I don't think we ever need that. As an aside object pickers could be handled as mixins or something similar... Another simpler idea is to install fallback handlers, i.e. everything that's not handled by the current tool is subject to 'default processing'. If this default processing is static in code or driven by some event processor depends on the degree of modularity required (think about 'event sieves', everything not handled pass down thru a 'chain' of handlers). IIRC gtk works that way. > In general, those that have worked with state machines know that they provide > benefits in > troubleshooting. What you have done is to essentially divide what would > otherwise be one > big state machine into smaller ones. And I think this is a great idea. :) I agree. The current 'left button' and 'right button' handlers are awfully huge switch statements. Something a little more modular would be helpful for the future :D > Exciting stuff, That's independently of the GAL, I think some/most of this stuff would be useful even for 'stock' kicad, however the GAL *requires* them... too bad you can't have the xor blend in opengl:((( I really prefer the xor contrast compared to Porter/Duff composition (maybe there is some shader trick but good luck having it work fast on the Intel GPUs...). Well, there *was* but it was deprecated together with color index mode and other 'non-photorealistic' stuff. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
