On 08/10/2013 09:28 AM, Lorenzo Marcantonio wrote: > 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?
wx has a stack of event handlers built into each event context. So what I describe is already written for you in wx, except the tests of the events, and that is either a switch or else ifs. I think this entire infrastructure in b) probably came from wx, its just that it lurked in my subconscious for a few months until I wrote that. The tools could be SWIGed, and this partitions the python function space into logical categories. That is, assuming you put the C++ handlers which to the actual work in the tools, maybe without wxEvent parameters, but with expanded C++ arguments so python does not have to fabricate an event to call them. 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. > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
