kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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, 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
> 
>