kicad-developers team mailing list archive

[Carl Poirier <carl.poirier.2@xxxxxxxxx>]

Coming from Mercurial, I prefer "branch, commit, push" rather than
"checkout, commit". :P

So I pushed one first set of changes. I renamed approximately 25 library
files, and for only a few of them, I renamed their 3d view files and more.
Please let me know if it looks alright. I'll then go on with the remaining.

Attached is the corresponding fp-lib-table.

Carl


On Tue, Nov 12, 2013 at 8:43 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

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

Attachment: fp-lib-table
Description: Binary data