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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
