kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/19/2013 4:14 AM, Lorenzo Marcantonio wrote:
> Some (mostly) trival observation from new users (I'm proselitizing :D),
> regarding the netlist dialog in pcbnew (it seems to be voted as the most
> obscure dialog in kicad):

The netlist dialog could use a little polish.

> 
> - For the 'module selection' option is RTFM time (i.e. nobody has an
>   idea of how that works); I agree and that's an exotic option anyway,
>   so I think it's a non issue.

Given how the modules can be updated from the netlist, I don't see how
we can do much to improve this without fundamentally changing the way we
update modules from the netlist.

> 
> - Module name source: myself I have no idea of why should be necessary
>   to select the source... there are worse problem if the netlist and the
>   cmp file mismatchs (but at least we got rid of the backannotation
>   file). I hope the plan for the future is to keep the netlist only
>   (what is the usefulness of the cmp file other than not having to pull
>   netlist code in cvpcb?)

There is a plan to dump the *.cmp file and use the new s-expression
netlist to handle module changes between Eeschema and Pcbnew.  This
should greatly simplify things.  This will not happen until we add
module assignment capability to Eeschema and hopefully get rid of CvPcb.
 Think of this as adding the functionality of CvPcb to both Eeschema and
Pcbnew so you can assign the modules either while capturing the
schematic (my preference) or before you layout the board.  Should we
ever get to point where KiCad runs in a single process, there would be
no need for an external netlist file and the schematic and the board
could be updated transparently.  All of these things have been discussed
and should be considered *very* long term goals.

> 
> - Exchange/delete extra/delete track mostly clear for everyone
> 
> - The 'only report changes in message panel' is the most misunderstood
>   option of all: I fell on that, too:D the intended meaning is 'only
>   report changes (but don't actually change anything)' i.e. a dry run
>   switch: it's actually useful since it works as a netlist compare (will
>   work even better when netnames are stable). However most people got it
>   as a 'tell me only stuff different from before, but change it anyway'.
>   Maybe a better label would be useful

I added this.  It's a dry run option so you could see what changes
loading the netlist would make to the board.  I did not want to use the
term "dry run" in the check box text.  That may be fine for developers
but I don't think "dry run" would be understood by most users.  Would
"Report changes in message panel below without making changes to board"
be more clear?  If not, I'm open to suggestion.

> 
> - The 'open netlist' had a better name in the past IIRC... people
>   wonder why doesn't happen anything :P maybe 'select netlist' or
>   'browse for netlist' would be better ('open' has a more active
>   connotation). In fact the file chooser caption is 'select netlist'!

"Browse for Netlist File" is a more accurate description.

> 
> - The rebuild button is another RTFM item :D in fact I only had to use
>   it for reasons untied to netlist processing... maybe it would be
>   stand better in the cleanup panel?
> 
> - Personally I find the confirmation for each reread annoying...
>   consider that other cads boasts about automatic netlist transfer; just
>   like the annotate dialog maybe a just-do-it-and-shut-up permanent
>   option would be useful.
> 

I can drop the warning message before the netlist changes are made if
that's the general consensus.  I don't have the time right now to create
a message box with a option to never display the warning again as I am
trying to get footprint library table implementation completed.

I will make these minor changes if we can agree on them.

Wayne