kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

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,
> > Tom
>
>
> 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) {}.

Regards,
Tom