kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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

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

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

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.

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)

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).

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:

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.

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)

-- 
Lorenzo Marcantonio
Logos Srl