kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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 <dick@xxxxxxxxxxx
>> <mailto:dick@xxxxxxxxxxx>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>     Unsubscribe : https://launchpad.net/~kicad-developers
>>     More help   : https://help.launchpad.net/ListHelp
>>
>>
>