← Back to team overview

kicad-developers team mailing list archive

Was: page selection dialog, everybody please comment

 

On Thu, Apr 18, 2013 at 12:35:01PM -0500, Dick Hollenbeck wrote:
> Lorenzo,
> 
> The page selection dialog was broken in rev 4081 by a change which collapsed
> 
> was from "USLedger" to "US Ledger".

Sorry my fault. I *really* tought it was a typo.

I'm really against exposing keyword/internal data to the user anyway.
And not only for internationalization purposes. It's a rule of work (look
around for surrogate keys) in database design for example to *never* expose
primary keys or internal ids to the user because (s)he *will* want them to be
changed. For example not even licence plate or chassis number are used as
primary key in fact since they *actually change* in real life, too: last year
here in Italy we changed every moped licence plate, for example...

I don't agree to their use as 'fixed keyword' in the files, for
a similar reason (the design of PAGE_INFO is discutible for other reasons,
too). I am still worried about extra layers (I need them and I worked a lot for
having them, too). If the user can't even rename ECO1 to something more useful
(still she *can* rename Inner1 to something else, so there is already a symbol
mapping in there!) I don't even want to think of the work needed to add support
for another couple or two of layers.

Since we're sexp based, just exploit one of the main feature of the sexp,
the 'symbol':

(layers (15 Component signal)
        (0 Copper signal)
        (16 B.Adhes user)
        (17 F.Adhes user)
        (18 B.Paste user)
        (19 F.Paste user)
        (20 B.SilkS user)
        (21 F.SilkS user)
        (22 B.Mask user)
        (23 F.Mask user)
        (24 Dwgs.User user)
        (25 Cmts.User user)
        (26 Eco1.User user)
        (27 Eco2.User user)
        (28 Edge.Cuts user))

Technically: layer is a symbol (the form car, in this case), 15 is a number (a
fixnum, most probably), Component is a symbol, signal is a symbol. Guess what,
in sexps there are no keywords (common lisp *has* a keyword concept but it's
only tied to the package facility; keywords *are* symbol, they only begin with
: to avoid namespace scoping). These sexp are not meant to be executed so no
quoting, it's fine. To highlight we're talking about symbols I'll use
 |Component| (another common lisp syntax since by default symbols are not case
sensitive, but that's not the issue, it's only to make clear I'm talking about
a symbol). It seems obvious that kicad sexps are case sensitive (or at least
case preserving).

The second element is the layer name, a symbol too; the third is mostly (only?) for specctra but let's say it's the layer type. We have to decide if the
layer primary key is the number or the symbol. Inside pcbnew in fact the number
is the key (LAYER_NUM for now is an int); for convenience you (quite rightly)
use decided to use the layer symbol for reference in the rest of the file:

(segment (start 121.92 140.97) (end 119.38 143.51) (width 0.508) (layer Copper) 
         (net 1) (status 800))

that's fine, referencing layer |Copper| it goes in layer 0. This is a single
faced board so I have called them |Copper| and |Component| (or maybe it was the old
default).

Moving on:

(gr_line (start 192.00114 71.99884) (end 117.00002 71.99884) (angle 90) 
         (layer Edge.Cuts))

please note |Edge.Cuts| is a symbol in the *same class* of |Copper|. Also an
italian user has *no idea* of what |Edge.Cuts| means (just as he has no idea of
what USLetter mean... it's called "Lettera" here, which is coincidental
similar; google translator give the equivalent German as "Briefbogen" which is
*quite* different...); a good name would be probably |Bordi|, for example (by
the way it's easier for an italian to know french than english).

So why not:

  (layers (15 Componenti signal)
          ;; OMISSIS
          (28 Bordi user))

and then

(gr_line (start 192.00114 71.99884) (end 117.00002 71.99884) (angle 90) (layer Bordi))

Here, pcbnew internally knows that layer 28 is the pcb border (if it wasn't so *why* put the layer number in the file?), associate the symbol |Bordi| to it and matching works fine. The same exact machinery in motion for saying |Copper| instead of |B.Cu|.

This is the design if the primary key is the layer number, in the file. It's arbitrary, and it's more or less the way eagle handles layers (by number). 

Let's decide (as an alternative design) the layer name symbol it's the primary key for pcbnew:

(layers (15 F.Cu signal)
        (0 B.Cu signal)
        ;; OMISSIS
        (28 Edge.Cuts user))

With this approach this won't work. If the symbol is the key what is the number for?
Also you lose the capability to rename even copper layers (pcbnew doesn't known what |Component| is). We could for example do this:

(layers (F.Cu signal "Componenti")
        ;; OMISSIS
        (Edge.Cuts user "Bordi"))

here the layer name is directly a string to show that's meant for user
consumption only (a symbol would be fine too, given the appropriate restriction
for the character set), since everywhere else F.Cu would be used; then tracks
would be:

(segment (start 121.92 140.97) (end 119.38 143.51) (width 0.508) (layer F.Cu) (net 1) 
         (status 800))

Still works fine.

Both of these approaches are consistent and still readable *both* for the user
and for whoever wants to dig into the file. However:

- The first way is actually compatible with the current format (just think the
  extra layers have kept the default name)

- The second choice need to allocate keywords for each new layer, while the
  first only requires to define a new number (it would need to be done anyway
  for the LAYER_NUM enum)

- The first way has the user layer names all around the file: better for the
  user but worse for us if he speak a strange language; I for example couldn't
  troubleshoot layer names in German or Dutch :D however the layer setup dialog
  could have a 'reset names' button for this.  The alternative would be having
  layer keywords in the file (fine, given the inconvenience above). 

- The current implementation has user names for copper and system keywords for
  the other layers, which is at least inconsistent. So I'd have anyway to look
  for traces on |Bestückungsseite| (assuming google translator is working :D)
  and borders on |Edge.Cuts|. Where is the advantage?

So, what's bad in allowing people to name layers as they want since they are
anyway identified by their number at the end?

I'd like to have feedback from everyone on these opinions.

-- 
Lorenzo Marcantonio
Logos Srl


Follow ups

References