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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
