On Mon, Aug 12, 2013 at 09:24:59AM -0500, Dick Hollenbeck wrote: > 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".
I don't see either why wxEvtHandler is not enough for his plan. OTOH since I don't know wx I had already thinked about some ad-hoc solution; I don't know if it can do everything it need to be done. IF and only if it need to only process user action events from what I have read it should be able to do its work (that's what is designed for!). If something more complex need to pass thru it (maybe high-level object selection events or something, I have no idea...) then maybe some evaluation is needed. I think that a prototype/dummy example/technology demo would be in order to evaluate the thing. > 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. wx data structures suck, so we use STL, for example. And Qt event routing is completely different (but I don't think that would be his reason). boost signals could be an option too (I'm not endorsing them, I only know they exist!). I don't exactly like boost but I don't like C++ either, so it's an acquired taste... Anyway, writing event dispatching code is one of the most boring thing in the world (maybe only second to tallying totals in cobol for a print), so a ready to use solution would be desiderable. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
