kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, Jul 02, 2014 at 08:50:26AM -0500, Dick Hollenbeck wrote:
> 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.

What I meant is that's a very localized test anyway. I wasn't talking
about performance issues. And anyway it's a reasonable design decision
to take.

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

Why split? ATM you have three column: Name, enabled, and type. Add
a column called 'User name' or 'comment' and keep the name fixed
forever. Some kind of user preference would then guide the id-to-name
decoding to show the internal name or the user name in the appropriate
UI pieces.

The non trivial task is finding all the UI pieces, I agree:D Also
there's the old problem of "layers lives in the board, the module editor
is on its own" (just use always the internal name when there is no
board around, exactly how we already do for copper layer renames).

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

Call them sexp, then. The general format is the same. What I always
argued is for user-definable names (comment name). *If* the layer set is
arbitrary (like eagle) then keyword names have to change; I think that's the thing
I said you are referring to. If the layer set is fixed (like altium)
then you can keep the internal names as keyword. Given that at last we
decided on a fixed style of layer then I would say that on the sexp is
perfectly useful something like:

(layers
    (:name Mech1 :comment "Fixtures"))
(line :layer Mech1 xxx xx xxx)

instead of

(layers
    (:name Fixtures))
(line :layer Fixtures xxx xx xxx)

The key part is having a user-definable name to attach to the layer tag.


> For the pretty format, we DO use the fixed names for Cu.  For the *.kicad_pcb format, we

Obviously, there is no board around to get another name from...

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

OK. No problem for that. Seemed to me a little easier to keep the layer
tags fixed; however in this case someone will argue "why can I rename
a copper layer and not a mech one?" just for consistency. And the mental
step would apply even when finding a problem with a user layer. Just
proposing to keep the format 'regular', but I actually have nothing
against this (user *will* ask for that, anyway:P)

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

Fixed names should be always valid so I don't see a problem with that...
and given that there is already the infrastructure to do that why not
use that. A feature using that would be layer groups.

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

Ah right. That's the only multilayer plot, I forgot. However IIRC this is mostly
a 'for layer from 1 to 32 { plot_layer }' so should be easy to adapt.

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

Could have been upcase at least :P they really stand out as variables
now. Who cares, really; I've seen worse coding convention around.

...now to test and see how much my files become broke with the new
format... (probably sed will suffice to fix... as you said is a good
file format). Otherwise I'll just feed it to a lisp read and fix it
programmatically. A problem of mine anyway.

-- 
Lorenzo Marcantonio
Logos Srl