On 08/10/2013 01:22 PM, Lorenzo Marcantonio wrote: > On Sat, Aug 10, 2013 at 09:53:40AM -0500, Dick Hollenbeck wrote: > >> 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. > > I only have one thing to say: please take care to not mix the model and > the view/controller... sanity check: could the same operation be done > from the scripting interface without calling the tool UI stuff? if not, > some refactoring could be useful. > >> 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. > > 100% agree on that. 'General' display/control stuff IMHO should reside > in the frame, unless it's some board-related preference: what is where > is debatable and subject to a design decision; example: the aux origin > is undeniably on the board, but should, say, the grid be tied to the > board or to the view?
Data can reside on the moon if you have accessors that hide that fact. The interface is the important thing, since it is what is propagated through the client code. In the case of the grid origin *data*, it had to be moved to the BOARD because PLUGINs have no access to the frame, only to the BOARD, and the grid origin wanted to be saved to disk as part of the board file. And BOARDs should not know about frames, so no accessor magic in the BOARD was possible. But again, the grid origin accessor is the important thing, and the code that uses it can use it just fine since it is in the frame. > > I think that these doubt should be cleared thinking on 'what about if we > could have two views on the same board' (which, incidentally, could be > a good feature in the far future) > That is a fairly fundamental decision, sort of like the decision you have to make before you start building: either a house or a boat. With rapid zoom in and out, a competing idea might be to store viewports as bookmarks. This is a combo of zoom and viewport origin, and maybe cursor position also. With the bookmark you could rapidly BOARD hop. I like full screen views, so I am less than neutral about multiple views for a BOARD. Schematic editor is a different discussion, there you can argue effectively for a tabbed multisheet frame, but I prefer a full frame view of each sheet. Near term, I would vote against multiple BOARD views and how that would affect the pcbnew code. 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
