← Back to team overview

kicad-developers team mailing list archive

Re: Kicad Tool Framework


On 08/13/2013 06:43 PM, Dick Hollenbeck wrote:
On 08/13/2013 10:58 AM, Tomasz Wlostowski wrote:
On 08/13/2013 05:48 PM, Lorenzo Marcantonio wrote:
On Tue, Aug 13, 2013 at 07:14:05AM -0500, Dick Hollenbeck wrote:
If you ignore the context of application, then this is the same thing as guessing that a
mechanic hates his 5mm wrench when he goes to loosen a 11mm nut.

I think it more than using a ratchet instead of an open wrench to loose
the nut. Same result, different way to do it.

Of course a really tight nut may require a long wrench and break the
ratchet... i.e. not necessarily coroutines are the solution.

The solution I proposed does not make coroutines obligatory. If you
don't want to use them in a particular tool, just don't call any
Wait()/Yield() methods. TOOL_INTERACTIVE constructor could have an
additional parameter that prevents creating an unnecessary stack frame
for coroutine-less tools.

As a way to maintain the tool state machine (fed by events), they seem
appropriate to me; of course everyone will propose his own 'best' idea
(heck, no women here:P)

Look at the PDF I put on ohwr.org - one can use coroutines, function
pointers or enum+switch for the FSMs, depending on his/her coding
habits. Nothing is forbidden.


I had not seen the PDF before I made my initial positive comments.  I had only read the
synopsis on the web page.  Maybe I missed it or maybe you added it recently.

I wonder how important building a team around this code is.   I wonder who will be on that
Whoever wants to join it :)

Alfons sunk 7 man years into the code before it was useable.  That suggests a team may be

When do we see the code?

For the P&S router: as soon as it stops crashing and leaking memory.

For the tool system: the proposal code has been in kicad-gal-orson branch since my first e-mail (~1.5 weeks). It shows a trivial selection tool that uses coroutines and non-wx events.