kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Aug 12, 2013 at 08:29:40PM +0200, Tomasz Wlostowski wrote:
> 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

Same here :D I'm giving some suggestion but I have no idea if can be
made working in wx... but maybe these could click an idea for someone.

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

Are you handling states with method pointers? It should be possible to
handle it with a 'stub' ProcessEvent which just call the 'current
state'. At least that's the way I do FSM (instead of coding and
switching on the state, the state variable contains the function for
handling it). Put it in the root of your handlers and forget it exists.

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

Technically UI commands should be classes, if you're going the OO way.
A typical trick is using singleton addresses as ids but I don't know if
it's doable in wx. C++ lack symbols:P

> nearby objects/grid and. It could be done on event level, by
> adjusting cursor coordinates accordingly.

Well maybe some tool need to work in screen space too. And converting
should be easy so I don't see that as a fundamental flaw. The important
thing is the roundtrip is possible.

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

Utility functions to handle this? Otherwise: can a wx handler *modify*
the event? then you could add 'filters' in the stack to handle this and
the previous point. But that would be stretching the wx architecture
IMHO.

> - No idea how wx event stack will play with coroutines:

I feel is not a good idea keeping a coroutine in an event call stack...
study of wx code is needed to ensure compability

> - Wanted to avoid translating between VECTOR2<>/BOX2<> and
> wxRect/wxPoint in the tools.

Can't we subclass the event to contain them? so it could even keep the
board/screen coordinates and stuff... or it's a closed class passed by
value? Ideally that would be populated in the 'first' filter which
receives the event.

> - (a less technical one) I'm slightly biased against wx, so I didn't
> want to depend too much on it:

A lot of people thinks that way :D but in a way or the other I couldn't
find a toolkit that simply works...

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

I *still* can't find the source of the dragging bug in eeschema. Must be
something like that, some critical ordering issue... 

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

I find track laying impossible without mouse warping... there is an
option to disable it. But how could you *emulate* it, if there is no way
to physically move the pointer? (of course pcbnew would greatly suck
with a tablet, if only for the required precision)

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

gtk printing is not *too* better... the only program I ever seen which
consistently printed correctly generate postscript on their own. I think
it's due to the impedance mismatch between the screen model and the
printing model (everyone want to do it with the same routines since
MFC... but it's fundamentally flawed as approach...)

-- 
Lorenzo Marcantonio
Logos Srl