← Back to team overview

kicad-developers team mailing list archive

Re: Kicad Tool Framework


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


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.

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


Follow ups