← Back to team overview

kicad-developers team mailing list archive

Re: kicad_pcb, kicad_mod format change for daily build?

 

Dick,

On 4/24/19 7:39 PM, Dick Hollenbeck wrote:
On 4/15/19 8:50 AM, jp charras wrote:
Le 15/04/2019 à 15:34, Jeff Young a écrit :
Yes, this was intentional.  It allows users to put things like spaces in layer names and other user-editable things.

I’ll fix up the STEP exporter….

On 15 Apr 2019, at 13:56, easyw <easyw@xxxxxxxxxxxx> wrote:

Hi,
recently I have noticed that both kicad_pcb and kicad_mod seems to have changed their format.
It have been introduced double quotes for layers pads etc.
Is that necessary or intentional?

Here two related issues links:
footprint
https://github.com/easyw/kicadStepUpMod/issues/13#issuecomment-481160108
pcb
https://forum.kicad.info/t/bad-layer-data-error-when-exporting-step/16322/11

and a small diff example:

(layers
    (0 F.Cu signal)
    (31 B.Cu signal)

(layers
    (0 "F.Cu" signal)
    (31 "B.Cu" signal)

Thanks
Maurice

Exactly, in these files, user strings (like fields, pad names, layer
names...) were previously quoted on request, i.e. if they contained a
space or some other special delimiter char.

Now they are always quoted, which is better: user strings are always
clearly identified.
This is not really a format change.

JP, I think you are blending syntax with grammar.   I do not understand the need for this
change and currently do not agree with it.  It creates noise in version control systems,
and makes the files bigger, for no real gain.

The save functions have always done a nice job of deciding whether a quote is necessary.
At this pace the files will end up looking like javascript before long, and will be noisy.

Dick

_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


I understand and share your concerns. This was not a decision made lightly but this change is on me. I gave the go ahead. It was a decision based on the lesser of three evils. The decision to allow users to rename copper layers and not rename non-copper layers when we implemented the new file format was probably less than ideal. We are in the process of allowing unrestricted layer names so quoting was inevitable and so now we are paying the price for the initial decision. I saw three potential paths forward:

Option 1:

Quote all layer names to prevent layer names from being both quoted and unquoted. Allowing both quoted and unquoted layer names would have been both ugly and confusing in the file format. The unfortunate side effect of always quoting all layer names is the noisier file format and the one time change which would be an issue for vcs users. The advantage is that this was that no additional coding was required to support unrestricted layer names on all layers. This option was the path of least effort which is why I chose it.

Option 2:

Force all layer names to the default name for all internal objects and add an optional quoted name to the layer definition. This option would maintain the naming symmetry and not require any quoting resulting in a smaller change set for vcs users who use the default names. For users who changed copper layer names, there would still be a one time larger change set hit. This also would have required a fair amount of code to check for renamed copper layers and rename the internal layer names to the default and all of the places in the code that display the user's preferred layer name would have to be updated.

Options 3:

Add optional layer name string only to the non-copper layers. This would make the layer table and the object layer names inconsistent. It would also complicate any code that uses the user defined layer names. This option would result in the least intrusive file changes.

I'm am not opposed to option 2 but there will be a one time hit for vcs users who rename their copper layers so I do not see any path forward where we don't have to make a compromise. I really don't like option 3. If you or anyone else has a better idea, I'm always open to suggestion.

I am traveling and have a busy schedule over the weekend so my response time will be a bit delayed.

Cheers,

Wayne


Follow ups

References