On 9/24/2013 6:17 PM, Dick Hollenbeck wrote: > > On Sep 24, 2013 5:14 PM, "Wayne Stambaugh" <[email protected] > <mailto:[email protected]>> wrote: >> >> On 9/24/2013 5:15 PM, Dick Hollenbeck wrote: >> > 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 >> > >> > >> That is how it's supposed to work unless there is some issue that I >> missed. The few projects that I tested it on seemed to work fine. Let >> me know if it's getting saved somewhere else and I will fix it. > > You did not answer my first question, I don't know where it gets saved > if no project. But it is.
Sorry about that. > > I like what I see, but wanted to examine the project table. Can not > find it for case when no project. That would be a bug on my part. It should not save the project fp-lib-table if no board file is loaded. Is there a way to not show the project specific tab in the footprint table edit dialog. That seems like a reasonable indicator to the user that no project footprint library table is not available. I'll take a look at the project footprint library table save code and make the necessary fixes. > > >> >> Wayne >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] > <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
