kicad-developers team mailing list archive
Mailing list archive
Re: Kicad Tool Framework
On 08/10/2013 04:28 PM, 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(...)
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).
> Another simpler idea is to install fallback handlers, i.e. everything
> that's not handled by the current tool is subject to 'default
IMHO It's a bit similar, but not exactly the same: events come to a tool
- it can then react and sometimes consume some of them so that other
tools (lower on the stack) don't receive these events anymore. Event
handlers are delegates (somewhat similar to signals/slots in Qt) and are
dispatched dynamically by the TOOL_MANAGER. This could be probably seen
as an enhanced virtual method mechanism... As for the default handlers -
there can be a tool permanently residing on the bottom of the stack and
dedicated for catching such events.
Do we need dynamic method
I wouldn't preclude such scenario. Having a 2-level stack is as complex
as having an N-level one.
composition? I.e. will tool A be *always* below tool B or there may be
a tool C below tool B?
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
Fully agree :)
Shaders aren't that bad under intel drivers (the GAL works just fine on
a core i7 integrated graphics on my latptop, although Half-life 2 - a
10-year old game doesn't because some texture formats are not
supported). Under Linux, if you want performance and truly
standard-compliant OpenGL, I'm afraid you have to use the evil Nvidia
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...).