kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/12/2013 10:09 AM, Tomasz Wlostowski wrote:
> 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.

Sorry it took me so long to look at this but I finally had some time
over the weekend.  Your design looks pretty ambitious.  I too was
surprised that the base tool class wasn't derived from wxEvtHandler.  It
appears that you effectively created your own event object and that
wxEvents will have to be converted to the new event type for processing
by the tool manager.  This seems like a lot of unnecessary complexity to
me when any class derived from wxEventHandler would handle wxEvents with
no additional code.  This way you could connect your tool to handle any
given wxEvent and then disconnect when the tool is no longer needed.
This should also make it easier to port existing code into the tool
framework.

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

wxEventHandler is part of the wxBase library which contains no UI code.
 See http://docs.wxwidgets.org/trunk/page_libs.html#page_libs_wxbase.
You can even use wxEventHandler in console applications.  It's not
limited to UI objects in any way that I can tell.  Is there any
technical reason not to use the wxWidgets event handling?

Wayne

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