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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp