kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

bzr push 

is almost always a mistake. 

 bzr commit 

is appropriate, but requires that your branch is a "checkout".  People who talk about pushing with bzr are often confused, more often than not.

BTW the COW talk should have been put into a separate posting.  It has no bearing on what you are doing.



Sent from my Galaxy S®III

-------- Original message --------
From: Carl Poirier <carl.poirier.2@xxxxxxxxx> 
Date: 11/12/2013  6:11 PM  (GMT-06:00) 
To: Dick Hollenbeck <dick@xxxxxxxxxxx> 
Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx> 
Subject: Re: [Kicad-developers] footprint library help needed 
 
There's lots of information for me to digest in there. I'll be looking at it more in details tomorrow, after I push a first batch of changes to the libraries.

Carl


On Tue, Nov 12, 2013 at 4:36 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
Thanks Carl.

I have finished my work on the fp-lib-table dialog editor today.  Carl, your work will
help make the wxGrid look sensible, and other than a long winded, too wide, circus.

I also finished its child options editor.  Options are separately supportable for each
kind of PLUGIN.  Each PLUGIN tells the options editor which options it supports, along
with "Internationalized HTML Help Text".

I have a number of phoney options compiled in for now, which will show up in the options
editor but not be supported in any plugin.  These are designed to ask questions and spur
ideas.  I plan on coding up actual support for *none* of these options myself, but you
will see the kind of concepts that it allows.

In the /new eeschema library design I had the notion of a LIB_SOURCE and a LIB_SINK.  That
let you read from one place and save to another.

Borrowing from that concept, it would be only a couple of hours to extend GITHUB_PLUGIN
from KICAD_PLUGIN, (maybe making stuff protected rather than private), and being able to
FootprintSave() in the GITHUB_PLUGIN locally.  Those saved footprints would be in their
own *.pretty dir, and would conceptually be combined with what is in the GITHUB repo.  It
would also represent your notion footprints that you would like to modify on the github
repo, and could be emailed to the library maintainer for his git push-ing.

This is Copy On Write (COW).  The lib_path for the base class KICAD_PLUGIN would come from
an option passed to the derived class, and it really is less than about 40 to 50 lines of
code, at most.  A volunteer is welcome to make this modification, I will not be.

But even without GITHUB_PLUGIN's COW, I think the project is best served by putting *all*
the libraries on github and dump the launchpad copies.  If the footprint subset of thos
libraries are saved in a way suitable for the github plugin, then a person would not need
to install them, and would always have up to date footprints.

Carl, I appreciate your help.  On this topic I feel like I am talking to in a nearly empty
cave, and you are the lone voice in the cave.


Regards,

Dick






> Yes, by the end of the week I'll push part of the whole refactoring, with a,b, and c done.
> I've been caught up by some exams last week, but it should be better now.
>
> Carl
>
>
> On Mon, Nov 11, 2013 at 4:30 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> wrote:
>
>     On 10/30/2013 10:31 AM, Dick Hollenbeck wrote:
>     >
>     > With the advent of the fp_lib_table support, we encounter some ill effects of long
>     > footprint library names.  Please see row 61 in attached *.png file.
>     >
>     > What I suggest be done:
>     >
>     > a) *Nicknames*: revise the template/fp-lib-table file wrt nicknames:
>     >   i) no longer than 25 characters
>     >   ii) adopt a consistent choice of capitalization
>     >
>     >
>     > b) shorten the name of *Library Path* entries, this means renaming most footprint
>     > libraries in the bzr repo to remove any reference to date or revision and to remove any
>     > inclusion of part names.
>     >
>     >
>     > c) add the previously existing references to part names which were in the library names,
>     > into the "Description" column of the fp-lib-table if the author so desires.
>
>     c) was modified to "Description" field should include about 50- 80 characters of
>     descriptive text, not necessarily originating from the filename.
>
>
>
>     Carl,
>
>     Any progress on a), b) or c)?
>
>
>     Will you be able to provide a new <kicad_src>/_global fp-lib-table soon, with updated
>     Descriptions field?
>
>     If not please say approximately when.
>
>
>     Thanks very much,
>
>     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
>
>