kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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