← Back to team overview

kicad-developers team mailing list archive

Re: Kicad Tool Framework


On 08/10/2013 03:27 PM, Dick Hollenbeck wrote:
On 08/02/2013 12:10 PM, Tomasz Wlostowski wrote:

There is a demo available (kicad-gal-orson branch), that shows a simple
selection tool (Go to Edit->Selection tool with the GAL view enabled).
It's not yet useful for any practical purposes and very unstable - It's
purpose is it just to show the overall idea and prepare ground for
technical discussion.

Thanks in advance for your feedback,

It looks great.

I have one minor feature that you would have probably added anyways, and that is a way to
handle persistent or default behaviours that are not addressed in any particular tool.

Hi Dick,

Sorry for late reply, I just come back from a mountaineering trip.
What do I mean by persistent behaviours?  Example:

I like being able to hit the space bar at any time to set the relative origin.  Would be
pain to put that into every tool.

For that I can suggest two things for you to think about:

a) If tools are extended from a base class, the persistent behaviours could be inherited.

b) If tools are pushed on a stack when they become active

I vote for b). If we go with inheritance, there is a risk that the TOOL_INTERACTIVE class will gain weight as more persistent behaviours are added.
, and if you have a mechanism
which the tool uses to report whether it handled an event or not, then if not handled you
can pass the event to the next tool on the stack.  With this strategy you put the
persistent behaviours into the baseline tool, and stack temporary other tools onto the
stack above it.  Although you can go to more that two high, this architecture does not
require that you do.
I didn't think about having tools on stack, it's a great idea! Initially I thought about writing a tool that simply triggers on persistent commands regardless of what other tool(s) are currently active - for instance, whenever a Ctrl+LMB click event arrives, the net under the cursor is highlighted (same for the relative grid command). A stack will probably make this cleaner and more ordered.

In general, those that have worked with state machines know that they provide benefits in
troubleshooting.  What you have done is to essentially divide what would otherwise be one
big state machine into smaller ones.  And I think this is a great idea.  :)
Thanks :) I didn't want to impose any particular way of writing these FSMs, every programmers has his/her own taste, so he's free to choose between coroutines, state-as-method or simply a switch(state) {}.


Follow ups