kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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