kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Tue, Jul 01, 2014 at 10:16:06AM -0500, Dick Hollenbeck wrote:
> JP, Wayne and I developed the following working blueprint and attached spreadsheet.
> Spreadsheet from JP.

OK pondered over this, here's what I think.
> 1) Wanted 32 CU layers, but wanted the stack flipped to match what the specctra format
>  used.  This is consistent with our layer setup dialog, it uses that same 
> sequence on presentation.

The stack is more or less an arbitrary convention so there should be no
problem. Other than people asking why we were counting inners from the
bottom. Nothing else to say on that.

> 2) Wanted 32 technical layers slots, although these have yet to be defined and I defer 
> to others on what is needed.   If a feature comes in a pair of layers, then they should
> be allocated in contiguous indices so as to not clutter the available space.

Reasonable. Even the pairing convention is quite good, if only for
allocating the sequence (IIRC there is a function which 'flips' the
layer, so technically wouldn't be an issue to do that otherwise).

> 3) Did not want to re-purpose any layer index, other than the CU layers.

Since copper is 32 layer it simply eats the old indices:P. Is that what
you meant?

> 4) Did not want to rename any technical layer, because wanted folks to be able to 
> look at the pretty format an understand it.  This means no translations or renaming.

Maybe a 'comment' field would be useful. Like Altium which has 'Mech 1',
'Mech 2', 'Mech 3' and then you could label them however you wanted. Of
course inside they are always Mech 1, Mech 2 and Mech 3... on the layer
dialog you would have the choice of the name to be seen (IIRC it goes
like Short Name, Long Name, Comment).

Also it would be probably more uniform to always use the 'internal' name
on I/O even for coppers and customizable layers (do we really need in
the pretty format to see 'VCC' instead of 'Inner1'?). So no layer rename
would be needed at all (just make the user fill the comment field).

Another thing, in the I/O instead of the hex masks I'd reuse the pad
list generation (much more readable *and* not tied to layer indices)

> I would suggest some iterators which can walk through a layer set.

Good idea, I like the LSET/LSEQ objects. Still have to study how the
works and the tricks employed. Hate these C++ idioms (like making
protected to make inaccessible...)

> 0) Define the new layers by name and purpose.

The CERN blueprint and maybe the suggestion from the gerber standards.
Personally with fabrication/courtyard the only thing I miss is maybe
a couple of paired 'comment' layers (for drawing things specific to
sides). With generic paired layers (if you can comment on their meaning, see
before) you can use pads to indicate plating, peelables and a lot of
things.

> 1)  Save/Load support to *.kicad_pcb.  It would be a good time to kill the 
> LEGACY_PLUGIN::Save().

Reasonable since it's quite a lot of time the new format is stable (and
anyway the old format can't cope with the new features). I confess that
in my branch the legacy code doesn't even handle compatible loading:P

> 2) LEGACY_PLUGIN::Load() would need to be reworked if the CU bit sequence
> is different in RAM.

Obvious:D I was lazy on that...

> 3) LAYER_WIDGET needs to show many more CU layers, might need a third tab and separate 
> technical and CU layers.

Or maybe some kind of scrolling? Having them always separated in
different tabs would be a nuisance with the 'usual' 4-layers; we could
do something 32 items in a tab and if needed open another one for the
others (assuming the limit is currently 64).

> 4) The layer setup dialog would need to be reworked.

Seems painful to do. Or at least I'm absolutely useless with the form
editor (last time I edited the XML...)

> 5) Would need to redo some plotter outputs based on the new CU bit order, and in the 
> course of doing that, we should go to a vector or array of LAYER_NUMs to establish a 
> specific order up front.

Why a specific output order for plots? I don't see why that would be
needed... wouldn't simply a list in 'layer order' suffice?

> 6) Add UI support for the various new layers.

Luckily many dialog already use the dialog chooser. The pad dialog
probably will need an heavier rework.

> I think I could do tasks 1) through 5) in a few days.  I am not volunteering for tasks
>  0) or 6).

So I'm not the only one which doesn't like UI work:P

> From that, I got a go ahead.  Then did a good bit of it, the patch was over 35,000 lines.
> Jean-Pierre helped, and that was appreciated.  Obviously something might have gotten broken.

Testing is for that :P The LAYER_NUM work was probably less of that, but
I agree it touched a lot of stuff. Especially changing the enum names
(I preferred the upcase one, since these are constant)

> 3) is not done.

Sorry, can't help on that other than the suggestion above; too wx
wizardry is needed

> 6) is not done.

Adding the new layers to the layer chooser should be simple. The problem
is that there is more than one of these choosers. IIRC there is already
the feature for 'omitting' the unwanted layers, at least in one of
these.

-- 
Lorenzo Marcantonio
Logos Srl