kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 08/12/2013 03:46 PM, Dick Hollenbeck wrote:
> On 08/12/2013 04:19 AM, Tomasz Wlostowski wrote:

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

I would really prefer to avoid mixing wxWidgets classes with the tool 
classes. My reasons are:
- tools should be invoke-able without launching any GUI or even without 
dependencies on the GUI library,
- tool events are board-space (coordinates) and adjusted to 
misbehaviours of wx on different platforms.
- deriving TOOL_BASE/TOOL_INTERACTIVE classes from wxEvtHandler will 
drag in wx dependency everywhere, which I find against the modularity 
concept. That's why I decided to have a separate TOOL_DISPATCHER class, 
which proxies wx events between the GUI (both frame and the draw panel) 
and the tools.

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

This is the current situation. Tools request certain types of events 
using Go() or Wait() statements, and the events are propagated to either 
the state handler (Go) or the next line of code (Wait).

Imagine the following chain of events
- router tool (top of stack) and persistent behaviour tool (bottom of 
stack) are active,
- user clicks CTRL-LMB,
- route tool hasn't requested such type of event, so it gets handled by 
the next tool in the stack,
- persistent behaviour tool receives the CTRL+LMB click and highlights 
the net below the cursor.

> 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.
I don't know much about abilities of SWIG, but can't it pass complex 
objects to C++ functions?
> 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.
They are not exposed to the programmer. By delegate I mean simply a 
pointer to a method in a particular object:

class myclass { void method() {} };
myclass myobject;

DELEGATE0<void> ptr (&myobject, &myclass::method );

ptr(); -> calls myobject::method.

So a transition in a tool FSM is defined by a set of trigger events and 
a state handler (the delegate).

Tom