kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/12/2013 09: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.
> 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.


Unfortunately, I guess I am losing my hope that we have a unified vision.

We apparently do not.

The project is based on wx.  The portions of wx that are objectionable, to me are:

graphics api, and wxString.


The rest of it are pretty nice.  We/you dodged the graphics api issue.  wxString is just a
disease we can live with.

If your concern is the ability to "link" a tool as a separate DLL/DSO without pulling in
wx code into that DLL/DSO, then I share that concern, but I don't think it is a problem, I
believe it can be done with some close investigation.


I am going to go away and cry now.  Go silent.  I was hopeful we had a unified vision, but
I fear we do not. Your document did not expose enough details.

When I was young like you my tendency was to over design everything.  I have since changed
to trying to find the simplest solution possible.  This has numerous benefits, not the
least of which is getting other folks to understand your concepts.  This is important in
our current situation because other folks have to write tools, and the API documentation
and infrastructure of wxEvtHandler is in place.

Maybe a way forward is for you to state why wxEvtHandler is not up to the task, without
using the explanation, "it is part of wx".

Ultimately, KiCad is built on wx, and to try and deny that seems like a pursuit without a
reward.  If and when you want to port KiCad to Qt, then replace wxEvtHandler then.

I don't have time to back and forth much on this right now.

Dick





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