On Apr 18, 2013 2:34 PM, "Lorenzo Marcantonio" <l.marcanto...@logossrl.com> wrote: > > 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 > >
This thread was about you breaking my code. And since it happened twice in one week, it is getting more difficult to work with you on any topic, let alone 8 topics in one email posting. Kicad needs to become more reliable before we add features that only a few people need. When the pretty format is in use, after that I would participate in more layer discussions. Right now, I am finding too many bugs in the software, and bad practices in your commits. It is not a good practice to commit code that you have advance knowledge of is disagreeable to one of the 3 main developers, as you did with LAYER_NUM. We might do well as a team by slowing down and focusing on reliability and quality not features for awhile. Firstly, the bugs are damaging to the project. _______________________________________________ > 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
_______________________________________________ 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