On 09/26/2013 11:14 AM, Dick Hollenbeck wrote: > On 09/26/2013 10:52 AM, Carl Poirier wrote: >> Hi Dick, >> >> I neither read the whole thread nor played with pretty yet, but if the steps >> to convert >> the libraries are fairly straightforward, I can volunteer to do it. I did >> however create >> many libraries in the old format so if needed, I will be able to validate >> the conversion. >> >> If you agree, please write down the steps required for the conversion and I >> will do it. > > Please tell me about your kicad environment: > > a) are you buiding your own? > > b) platform? > > c) have you built with python scripting yet? > > If c) is yes,
bzr co bzr+ssh://bazaar.launchpad.net/~kicad-lib-committers/kicad/library/ legacy To get all the libraries *as of today*, buy you maybe have already done this. If so, then it is simply $ cd legacy $ bzr up to get today's libraries. > then try reading the instructions at the top of > > <kicad_src>/scripts/lib_convert.py > > Me no python guru. > > Step 3) is the actual conversion. The smd_dil would be replaced for each > library. In > this example there, smd_dil.pretty is actually a subdirectory. The > *.kicad_mods will go > into that directory. > > This suggests having a master directory above that, say called > pretty_footprints somewhere > to stage this work. In there you would generate a series of *.pretty dirs, > one for each > library. > > Then build kicad with FP_LIB_TABLE support. Create table rows in > > pcbnew -> Preferences -> Library Tables. > > One row for each *.pretty directory. This table can be copied to and from a > spreadsheet > for editing. Select a region, righ mouse click, paste into a spreadsheet. > Get it right, > copy it back. The type should be "Kicad" for pretty libraries. The Nickname > can be > anything, typically the directory name without .pretty extension. > > Go into the module viewer, do some sampling, see your pretty footprints. > Establish > confidence or talk of problems. > > Thank you. > > >> >> Carl Poirier >> >> >> On Thu, Sep 26, 2013 at 10:39 AM, Dick Hollenbeck <[email protected] >> <mailto:[email protected]>> wrote: >> >> I checked the size of our largest footprint library and when zipped it >> scrunches to >> 70kbytes. >> >> This was not pretty, but legacy. But I don't anticipate a noteworthy >> difference in size. >> >> Therefore the concept of getting 70kbytes in one https://github.com hit >> seems reasonable >> even with country folks like me with slow internet access. My internet >> speed is only >> 160bytes / second. So the download time of this 70kbytes file, after it >> is zipped and the >> https session is established, will be less than a second. Maybe 1-3 >> seconds total with >> SSL session establishment overhead, depending on github load and >> internet whims. >> >> >> I am encouraged, and I think I will end up using this plugin as my main >> means of getting >> footprints, period. >> >> >> If no one volunteers, I have it on my to do list to convert what we have >> to pretty, then >> push it to github. I would use lib_convert.py to do this, for each >> library. >> >> If someone else wants to do it, that would be helpful. I certainly >> understand the "show >> me" mentality. If you've yet to see the GITHUB_PLUGIN work, then why >> would you invest >> time in this? I understand that. But I've also seen it work, so I am >> confident that >> somebody will probably step up in the near future. >> >> Just yesterday I made a tweak to the pretty output which tries to put >> pads on one line if >> they are not tricked out with optional attributes. That would be the >> format to use, from >> a build at least that new I suppose. >> >> Also, note that a library repo can be pushed with a README.md file, and >> in that file you >> could elaborate on and include an index of all footprints in the library >> in freeform text. >> This way a person could web-browse there and read about footprint >> choices first, in >> potentially great detail. >> >> Note that although subdirectories can be used in the repo, this view is >> flattened as the >> plugin unzips the footprints into its cache. So if you use >> subdirectories, make sure you >> have unique footprint names. With the upcoming options support, it will >> be possible to >> build in directory filters or other tricks into the plugin. But that >> will be for some >> other developer to do. I will provide the options support to all >> plugins. >> >> Beyond that, there is also the ability to comment each footprint in the >> *.kicad_mod file, >> manually using a text editor for now. The *first* lines of >> >> # ... anything >> >> are ignored by pcbnew. This may not be as helpful as the table of >> contents in the >> README.md file. >> >> You can sort of tell that this infrastructure is screaming for >> leadership. I don't see >> where that leadership needs to come from a programmer/developer. It is >> simple >> administration and guideline establishment. >> >> But yes, it is still a little early, we've got to get it running on all >> the platforms >> first. Our thanks go to Brian, Miguel and anyone else helping with that. >> >> >> Dick >> >> >> >> _______________________________________________ >> 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
