kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Mon, Aug 13, 2012 at 12:15:53AM -0500, Dick Hollenbeck wrote:
> But since BOARD_ACTIONS could also stand alone, the scripting could use it in a form
> independent of PCB_EDIT_FRAME.  
> 
> That might give you the best of both worlds then.
> 
> Another nice thing about this design and plan is that it can be done evolutionary, i.e.
> over time.

Why should we use a class, it's simply procedural code... a namespace is
at most all that's needed (this is C++, not Java!); unless you're
thinking about a command pattern which would be hell to implement, given
how undo is handled (that was already discussed years ago IIRC).

While I'm here, refactoring the plot routines outside the frame is more
difficult than I tought... the issue is 'simply' that from a BOARD you
simply cannot reach all the needed informations! The biggest problem
(for pcbnew) is the file name, needed for the title block and as a base
for plot filenames. This is not stored in the board but in the
PCB_SCREEN. AFAIK there is no way to reach it just with a BOARD
pointer...

Other things needed for the title block (but the issue is only for
eeschema) that comes from the SCREEN are the sheet number and number of
sheet; also the sheet description (i.e. the sheet path in eeschema)
comes from the FRAME via a virtual (and ultimately from the SCREEN).

For a board my only missing piece is the filename (since it's a single
sheet plot anyway) and I currently need to pass it during the plot call.
However it should come from the BOARD too, but I fear the repercussions
of such a change:P also that's not trivial since the BOARD is *not*
accessible from the SCREEN, but only from the BASE_PCB_FRAME.

The fact that the filename is in the SCREEN is also shared with
eeschema; I'd like to *not* touch it...

Any idea on how to handle this mess? Is there an access path I didn't
see?

-- 
Lorenzo Marcantonio
Logos Srl