kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/24/2013 3:34 PM, Lorenzo Marcantonio wrote:
> Premise: I don't get why this was done, since I find the existing
> library-order search perfectly adequate, however it's an interesting
> idea and obviously must have its merits (simply I can't see them, I need
> better glasses or a different workflow :P). Also I use the 'board as
> a library' approach suggested in the manual i.e. I never use the library
> related operations in the module editor. Create footprint archive does
> the library creation step for everything (for now it supports only the
> legacy mod files, will that change with the new file-for-module
> libraries?)
> 
> First of all: very good the environment variable replacement idea; a lot
> of symlinks trickery was required to make it work for different users. 
> 
> Tried to play with the library path dialog and it's good. I presume that
> the 'path' column changes significance depending on the plugin (a .mod
> file for legacy, a directory for the new format and so on); that plus
> the path substitution makes impossible a 'browse' button for the
> path...however I think that nearly immediately users will ask for it! 
> In fact I have many libs and I generated the fp file with a shell one
> liner:P

The ability to use any footprint library that is supported by a plugin
without having to convert them to one of Pcbnew's formats is important
for some users and certainly is more convenient.

> 
> Has the description column some significance or it's only a remark?

It's just a remark that gets saved in the footprint library table entry.

> 
> Possibly useful enhancement: while playing I added an inexistant pathname... the
> next cvpcb run it said: 
> 
> Some files are invalid!
> IO_ERROR: Footprint library path does not exist <<< here the missing file would be useful
> from /home/lomarcan/cvswork/kicad-bzr/pcbnew/kicad_plugin.cpp : Load() : line 214

I'll take a look at it.  I did fix a few bugs in r4345 so I may have
already fixed it.

> 
> Another thing trapped by my wx debug build:
> 
> ASSERT INFO:
> ./src/generic/listctrl.cpp(3063): assert "col >= 0 && col < GetColumnCount()" failed in SetColumnWidth(): invalid column index
> 
> BACKTRACE:
> [1] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
> [2] wxGenericListCtrl::SetColumnWidth(int, int)
> [3] FOOTPRINTS_LISTBOX::SetFootprints(FOOTPRINT_LIST&, wxString const&, COMPONENT*, int)
> [4] CVPCB_MAINFRAME::BuildFOOTPRINTS_LISTBOX()
> [5] CVPCB_MAINFRAME::ReadNetListAndLinkFiles()
> 
> It does so often (every time it repopulates the right column), and I see
> no sign of column resizing... I have seen the bug comment in the code
> and it trips even on wx 2.9 with gtk-2.0. That's just for information.

This one should be fixed in r4345.

> 
> Then I tried to 'update' a couple of components: it was C0805 (old
> package), then become smd:C0805. Everything fine till now, saved the cmp
> file without problems. Maybe one day the cmp file will go away and only
> the netlist will survive :D (the problem is when a part is deleted and
> a new one get its refdes... from the cmp file it takes the *old*
> package, which is bad)

At some point, I plan on doing away with the cmp file.  I have to write
the code so Pcbnew can save the new s-expr netlist file.  Once that's
done, cmp files will go away as will the legacy netlist files.

> 
> Backannotation in eeschema, it works as expected. However there is
> a catch: the 'qualified' names are usually way too long to be shown in
> the drawing. Maybe an option to display only the 'short' name would be
> useful (only display, the attribute must remain intact).

You might want to have a talk with library folks about the length of the
file and footprint names.  Is it really necessary to have a library
named Allegro_ACS754_ACS755_ACS756_HallCurrentSensor_RevA with a
footprint named Allegro_HallSensor_Package-CB-PFF_24Oct2012?  I would
think allegro_hall_current_sense and package_cb_pff would be plenty
readable without wrapping on a 1920X1200 monitor.  You can always change
the library nicknames to something shorter.

> 
> Back to pcbnew... tried to refresh the netlist. As expected it noticed
> a mismatch (names from cmp, keep modules), however it says:
> 
> Warning: component `C8` has footprint <C0805> and should be  <C0805>
> 
> I'd expected to read "should be <smd:C0805>", or am I wrong? during
> actual replacement the message is correct, anyway:

You are correct.  I missed that.  I'll add it to the list.  At least it
replaces with the correct footprints.

> 
> Replacing component "C8:/4BA0B4A0" footprint "C0805" with "smd:C0805".
> 
> (is that timestamp really useful? maybe when selecting using timestamps
> and not references... but then it would be useful in the previous
> message too)
> 
> Editing the replaced component shows the qualified name in the
> 'footprint name in library'... I think this need a little caution,
> however; this is because of how libraries are made.
> 
> - In a project board that value represents from which library the
>   component came from and the module name.
> 
> - In a master board for library creation that is the module name but, in
>   fact, the library has not significance (since we are going to write in
>   a specific, maybe new, library). In fact during the archival process
>   the library nick is simply stripped (I'd have done the same).  Still
>   I don't get *why* it takes so long:P
> 
> Maybe would be probably better to split the field in the module
> properties? It needs some more thinking.

I still have some testing to do with the footprint editor.  I'll see if
I can make it more user friendly in this regard.

> 
> All in all it seems to work... I'm using it and if something else pops
> up I'll let you know. Having the multiple library backend and variable
> substitution is surely an improvement from the previous implementation.
> 
> One last thing: I think we should stop polluting the home directory.
> With non-dot files, even! By the way, why are lock files there instead
> of aside the original files like before? it is an accepted practice
> (like the .*.swp files for vi) and doesn't pollute the home. Frankly
> I find all these _home_lomarcan*lock files quite ugly. Now there is the
> fp-lib-table which is a permanent file too... why not allocate a .kicad
> or a .config/kicad directory and put all that cruft there (with the
> individual .eeschema, .pcbnew files and so on, too)?  (Application Data
> would be the equivalent for Windows systems)
> 

I agree.  This is already on my list as well.  At some point, I plan on
moving all the KiCad config files into the .kicad folder in the user's
home folder on Linux.  Unfortunately, there is no easy way to do this
for Windows users.  Converting the KiCad configuration settings in the
registry to config files is not trivial.  I may make Windows user's
reconfigure KiCad rather than try to convert the registry entries when I
get around to this.

Thanks for the help,

Wayne