LibrePCB / librepcb-rfcs

MOVED TO https://librepcb.discourse.group/
Apache License 2.0
3 stars 0 forks source link

Change attribute substitution syntax? #14

Closed ubruhin closed 6 years ago

ubruhin commented 6 years ago

The attributes system is documented here: http://librepcb.org/LibrePCB-Doxygen/master/de/df4/doc_attributes_system.html

So the syntax is e.g. #VALUE, or if multiple key substitution is needed (use fallbacks if a key is not defined) #PARTNUMBER|DEVICE|COMPONENT. Optionally the string "||" can be used to manually mark the end of a key.

But this syntax feels a bit strange to me. As an example, I tried to use it to automatically generate filepaths for the output gerber files based on attributes. Such paths may look like that:

./output/#VERSION/gerber/#PROJECT||_#BOARD||_COPPER-TOP.gbr

Unfortunately the "||" are needed, otherwise the underscores are considered as part of the attribute keys. But this really looks strange. So I wonder if we should adjust the syntax of attributes. If we plan to do it, we should really do it now! Later, after a first release, it would probably be a nightmare to change that syntax because attributes are used everywhere.

One idea is to use a more bash-like syntax, for example a simple attribute would look like that:

$VALUE

So basically only # is replaced by $. But then we should also support this extended syntax:

${VALUE}

which also allows to define fallback keys, for example like that:

${PARTNUMBER:DEVICE:COMPONENT}

The filepath from above would then look like that:

./output/$VERSION/gerber/${PROJECT}_${BOARD}_COPPER-TOP.gbr

Another variant would be Jinja2 syntax, e.g.:

{{VALUE}}

And to specify fallbacks:

{{PARTNUMBER or DEVICE or COMPONENT}}

Filepath:

./output/{{VERSION}}/gerber/{{PROJECT}}_{{BOARD}}_COPPER-TOP.gbr

One drawback is that it leads to longer texts (some symbols lead to overlapping texts in the symbol editor if texts are too long)...

I'm really not sure what to do. But I think we need to change at least something ;)

dbrgn commented 6 years ago

I think both bash and jinja syntax look much nicer!

I don't have a preference for one or the other. I think the jinja version is more readable, but there are probably more people familiar with the bash syntax.

ubruhin commented 6 years ago

I tend to use the jinja syntax, especially because the potential of future extensions is huge. Jinja has many features (e.g. filters) which may also be useful for us, so we could implement them too.

How it looks in the symbol and footprint editors:

auswahl_011

auswahl_010

ubruhin commented 6 years ago

Done in https://github.com/LibrePCB/LibrePCB/pull/254.