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