On Tue, Aug 14, 2012 at 04:24:02PM -0500, Dick Hollenbeck wrote: > Of course you should be able to eventually. Here again below is my vision > for > re-architecting the link images comprising KiCad suite.
Now it's working... more or less:P since the board get deleted and recreated it loses the filename somewhere in the process, I've to pinpoint it > For Pcbnew, BOARD_ACTIONS is a way to cleave off the procedural code, away > from the UI > code, yet still have it exist tightly bound within the frame, just like now. I don't see why the board should be tightly bound with the frame... the board has its behaviour and the frame only manipulate it. Another thing I've seen too often is the visual-basicish thing of doing all the stuff (the use case) inside the dialog (the plot is an example of this), precluding doing the same stuff without UI. As a counter-example DRC is done better. > We are not there yet, because of spaghetti. It's the Italians' fault, > really. If we did > not have spaghetti, we would not have this problem. It's spaghetti when you have jumps; in OO it's called ravioli code XD and BTW I'm Italian, too, so I'm an expert in pasta issues :P:P oh and even without spaghetti you'd have yakisoba code, udon code and ramen code, the true ancestors! > Part of separating things means finding sensible boundaries, a.k.a. > interfaces. > But only the procedural code. All the argument gathering which is happening > in the > dialogs, gets done, and then the procedural code is called in BOARD_ACTIONS > to actually do > the work. My idea it to pull the procedural code *out* of the frame (to the limit of UI, obviously) and a) in some BOARD_ACTIONS class or b) as standalone code (since it has near-to-zero state), manipulating the BOARD. Example use case: drawing a track (simplified) - User tell the FRAME (s)he wants to draw a track; frame switches mode and (using an action queries BOARD) picks the starting point - User moves cursor to pull the track; frame uses an action to determine how the track will like and if it passes DRC, then show a preview to the user - User confirm track; FRAME uses an action to do this; the action coordinates BOARD and the track objects to finalize things Implemented this the scripting interface (or something else) can now: a) query the track under a point b) ask for the layout/correctness of a new track segment and c) lay down tracks. This allows to, for example, create a script to do differential meanders (one of my nightmares) which BTW were added to eagle 6 as native code (and not as ULP) Anyway is almost exactly as you said, I simply don't see why the frame should be a mixin of the actions... > which is useful for both scripting and by a thinner pcbnew process image. Well, the process *image* would be the same... the executable file would be smaller. > BTW BASE_SCREEN's biggest problem is that is is trying to make Pcbnew > similar to Eeschema > and vice versa. This is not helpful. Having the freedom to evolve in > separate directions > is more important at this point. So BASE_SCREEN is no at all helpful in my > view. Also Some things are very similar, for example the frame/title block which I'm using. The real issue is what the contract for the SCREEN: - The BOARD keeps the model - The FRAME handles UI - What does the SCREEN do??? (in eeschema it keeps the model!!!) (functions/action classes uses BOARD to implement use cases on behalf of FRAME or scripting) The fun thing is that all this separation/layering is not a new OO idea but in fact was already use at least in the '60... CICS code (COBOL usually, you're allowed to vomit:P) is done this way and the routines doing the transaction are usually *in a whole different program* (i.e. another load image). In fact for a simple map (the CICS name for a form) you have: the map program itself (driving the terminal, in macro assembly), the map handling program (handles user interaction) and the TP routines proper (do stuff with databases); also the whole system was semiconversational (the map handling was done *exactly* like CGIs) and mostly RESTful... I think that IBM hadn't done a lot of work to attach a web interface to it... -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
