kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:
> 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
>  > processing'.
> 
> Hi Lorenzo,
> 
> 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.


http://docs.wxwidgets.org/trunk/classwx_evt_handler.html#a78719e8b82c9f9c6e4056b3449df1943


The Connect() method lets you connect wxEvtHandlers together.  Seems like the base tool
clase should be derived from wxEvtHandler.  Significant building blocks of the
infrastructure is already in wx that I can tell.

My "buy in" for the tool concept is premised on the notion that the handler functions
would exist in the tool which received the event, this is the knowledge encapsulation and
the modularity value proposition.


If we extend wxEvtHandler, then we can examine events either in

virtual bool 	ProcessEvent (wxEvent &event)

or in a hooked in handler via Connect() but in either case it would be nice to have the
initial handler:

a) reside in the tool, and

b) expand the event arguments into primitive variable types and call a member function,
still in the tool, using non-event i.e. primitive argument types, so that such latter
function can be SWIGed.


The talk about delegates makes me slightly nervous, because to me it connotes an
additional class, and that is not what I bought into.  It strays from the encapsulation
concept that I found so attractive.


Dick





> 
>   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?
> I wouldn't preclude such scenario. Having a 2-level stack is as complex 
> as having an N-level one.
>>
>> 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 :)
>>
>>> 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...).
> 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 
> binary driver...
> 
> Regard,
> Tom
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>