kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Apr 18, 2013 2:34 PM, "Lorenzo Marcantonio" <l.marcantonio@xxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp