kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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