On 08/10/2013 08:27 AM, 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. > > 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, 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. > > 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. :)
After more thought, and a long walk, I like it even more. I guess you are talking putting full featured board actions or procedural handlers in the tool also? This opens up the architecture quite a bit to extensions and is an outstanding idea Tom. The question of data accessors comes up though, and where is the data kept pertinent to the display, stuff which might be shared across tools yet is not related to the BOARD. I still think the frame is the best place for that data, if it cross-tool, else of course in the tool. For the data in the frame, maybe try and put the accessors in the base class tool. And declare that class a friend of the frame. This at least keeps the interface to the data clean, the tools really don't have to know where such frame resident data is. Other than that sticky spot, I think the benefits of bundling the know how with the state machine is a very major positive architectural change. Well done Tom. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
