kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/02/2014 07:46 AM, Lorenzo Marcantonio wrote:
> 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).

This is one of the use cases which argues for the fixed indices of each layer.  If you
first had to lookup the index, then do the flipping, it would be an extra step.  This sort
of answers your question below at 3).  Performance is a context specific concern, but when
you need it, you don't want the ball and chain.


>> 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).

Would need to split the layer setup dialog into two, but not a bad idea.  I spent a half
day on it just to get it to 32 Cu layers and the new Margin.  This is not a trivial task
to take it all the way to where you say.


> 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).

This is an interesting position for you to take.  As I think we've swapped opinions in the
last 3 years on this.   (First, the name "pretty" historically only refers to the
*.kicad_mod files.  If folks want to expand that, I cannot stop it.  The *.kicad_pcb
format needs a name, but maybe *.kicad_pcb is good enough.)

We went to the *.kicad_pcb format for human readability.  I think we achieved it in a
grand way.  Credit to Wayne.  It is cake to go in there and delete a zone, or copy one, etc.

For the pretty format, we DO use the fixed names for Cu.  For the *.kicad_pcb format, we
use the renamed Cu names.  The latter requires the context of the BOARD to make sense of
the names, but I think they do make more sense and I think the file is more readable to
the guy who is troubleshooting a problem.  If you were going to ask him to do a mental
translation, then we might have used layer number rather than layer name.  So this argues
strongly for the status quo.  We put a tremendous amount of thought into this 2 years ago.


The *.kicad_pcb format did its job, the Cu stack was flipped, the technicals were
re-assigned, and this magic was possible because of a good file format.


> 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)

This happens at most twice, and I agree with you.  It was also JP's observation.  We have
code to do this easily.  It is not a widescale problem.  A) plot params and B) one place
else.  But here we probably do need to use the fixed Cu names since we probably don't have
the name translation context.

This would be a positive change.  I can do this rather easily with code re-use.


>> 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

As I said, done.


>> 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...

done.

>> 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...)

done.


>> 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?


I was thinking about the SVG plot bug report.  On the combined layer [color] output, the
last guy wins, which is the layer on top in the rendering.  However the structuring of
plot support would not let me inject the clever LSEQ in as a rescue to this problem.

The looping and program flow needs to be reworked to accept the LSEQ.


>> 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


I am OK at it, as good as I want to be.  But I choose not to play smartest guy in the room
WRT to user need.  Software development and need assessment are two different things.
Then, after the user need is identified, I note that it is not my user need.  So therefore
I would not be inclined to fund it.

>> 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)

I wanted to attain familiarity with those concise layer names, which developers see in
their *.kicad_pcb files.  This was a deliberate decision.


>> 3) is not done.
> 
> Sorry, can't help on that other than the suggestion above; too wx
> wizardry is needed


I told Wayne and JP I'd do 3), so I guess I have to follow through, and make like I
actually have a 32 layer board to make.  I am not volunteering to fix the combobox however
if it does not work.  Just the layer widget.


>> 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.
>