kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/12/2013 2:29 PM, Tomasz Wlostowski wrote:
> On 08/12/2013 04:24 PM, Dick Hollenbeck wrote:
>>
>>
>> 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:
> 
> Dick, Wayne,
> 
> I said I'd prefer to not use wxEvtHandler for deriving the tools from,
> but the tool framework code is at a proposal stage, so everything can be
> changed.
> 
> I did my own event system, because I wanted to test some concepts (such
> as FSM state switching and coroutines) which are orthogonal to any UI
> library. I'm not a wxWidgets guru, and perhaps most of my requirements
> could be met with some hacking of the wx's event system - I'm asking for
> your help here. The reasons why I didn't use wxEvent/wxEvtHandler right
> away are below:
> 
> - wxEvtHandler specifies a single method for handling events:
> 
> virtual bool ProcessEvent().
> 
> My idea was to have states in separate methods. One reason is avoid
> enumerating states (and a big switch() statement in
> MY_TOOL::ProcessEvent()), another is that with states in methods, FSMs
> could be easily specialized by inheritance. I guess it should be
> possible to do the same using a wxEventHandler. The base tool class
> derived from wxEvtHandler could implement its own ProcessEvent() with
> reworked dispatching code from TOOL_MANAGER, that calls the actual state
> handlers and/or wakes them coroutines.

This was pretty much what I was thinking.  Derive from wxEvtHandler and
override any methods to get your desired behavior an add new methods to
cover the use cases specific to the tool event implementation.

> 
> - AFAIK wx uses integer IDs for defining UI commands. These IDs should
> to be globally unique, which may be hard to meet, as the project grows
> and many people contribute tool plugins. I chose to call tools by name.
> I'm fine with wxEvents if we find a way to ensure that all IDs (also
> across plugins) are easy to register and unique (hashes?).

Unfortunately the wxWidgets folks deprecated ::wxNewId() for 2.9.  That
used to be the way to do it.  Unique IDs are typically used in command
events for menus and toolbars.  I don't think IDs have any meaning for
other events like wxMouseEvent.

> 
> - wx mouse events work in window space, tools work in board space:
> 
> I assumed that events passed to the tools will be adjusted to the
> current state of the view. For example if the view is being
> auto-scrolled (because the mouse is
> near the edge), the tools should receive a series of mouse motion events
> because the cursor moves with respect to the world. Probably overloading
> wxMouseEvent could fix it, but this brings extra complexity too. In wx,
> mouse events are in screen space (GetLogicalPosition works for wxDC, but
> not for the GAL which has a non-wx-related coordinate system) - so the
> adjustment will have to be done in each state handler method or through
> some global event filter. The former is not too elegant, and I don't
> know if the latter is possible. You have much more experience with
> wxWidgets than me - what do you think about this? Then, there is a
> problem of distinguishing between events with board-relative coordinates
> with plain wx mouse events that might be injected from other sources
> (scripts). Also, tools should be able to request mouse snapping to
> nearby objects/grid and. It could be done on event level, by adjusting
> cursor coordinates accordingly.

Typically wxMouseEvent::GetLogicalPosition() is used to translate from
device coordinates to logical (world) coordinates.  It shouldn't be too
hard to derive from wxMouseEvent() and add an overloaded version of
GetLogicalPosition() that takes an OpenGL context instead of a wxDC to
calculate the logical coordinates.

> 
> - Drag vs click filtering:
> 
> Wx gives raw events. A click with a tiny mouse movement is considered a
> drag, unless some filtering is applied, so an intermediate event filter
> is required. I did it in TOOL_DISPATCHER class - maybe it could be
> integrated into wx event stack and work on wxEvent derivatives?

As of 2.9.3 wxWidgets supports event filtering via wxEventFilter.
Unfortunately, in 2.8 you would have to add a filter to the event
handler chain to pull this off.

> 
> - No idea how wx event stack will play with coroutines:
> 
> One of the key points of my proposal was the ability to handle events in
> a loop, a thing that we consider really useful and simplifying tool
> development (a small demo is in pcbnew/tools/selection_tool.cpp in
> kicad-gal-orson branch). Is it possible to marry coroutines with the wx
> event system? It would be great if so, otherwise, me & Orson would miss
> them very much (after all, P&S and interactive selection tools that we
> are developing are the most complex ones, that really benefit from all
> goodies of the tool framework...).

As of 2.9 wxWidgets supports event loops via wxEventLoopBase and
wxEventLoopActivator().  They may not be useful for what you are trying
to do.  Pulling this off in 2.8 would probably be cumbersome.

> 
> - Wanted to avoid translating between VECTOR2<>/BOX2<> and
> wxRect/wxPoint in the tools.
> 
> - (a less technical one) I'm slightly biased against wx, so I didn't
> want to depend too much on it:
>   * Different way of handling events on different plaforms: Let me give
> an example - the selection tool opens a pop-up menu when multiple items
> are clicked. We wanted to add some visual feedback that draws a bright,
> contrast border of the item you're about to select from the
> clarification menu. Then we discovered that it doesn't work on Windows:
> under Linux, a menu choice event comes after a menu close event, on
> Windows the order is opposite. I don't know if wx provides a mechanism
> for filtering and reordering events and if it can be adapted to fix such
> issues.
>   * Mouse warping is forbidden on some OSes: emulate it (transparently
> to the tools, so mouse events need to be adjusted somewhere) or drop it.
> Existing Kicad tools use mouse warping quite frequently, so it's an
> important issue.
>   * Linux issues: printing never, ever worked for me and the
> never-ending story of incompatible versions, which gave me bad feelings
> about general quality of the wxWidgets project and its packages in
> different distros.

No argument here.  Printing on Linux has always been poor.

Wayne

> 
> Regards,
> Tom
> 
>