kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.
>