On 09/24/2013 03:14 PM, Wayne Stambaugh wrote: > 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.
Where does the project specific table get saved to when I have to establish a project, but rather have simply started pcbnew from the command line without a filename? Otherwise I assume it is saved in the same dir as the *.kicad_pcb? Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
