kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

I hope you had our <kicad_src>/rules file in your

  ~/.bazaar/

directory.

Otherwise we have a rather large mess on our hands.

I don't know that an uncommit works against a push.

We will ask that somebody with a pristine library repo not update for a moment until we
can confirm.


I don't give a shit about wrl files, I just want the fp-lib-table editor to look nice, and
that means shorter stuff.


Dick




On 11/13/2013 11:51 AM, Carl Poirier wrote:
> 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
> <mailto: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 <mailto:carl.poirier.2@xxxxxxxxx>>
>     Date: 11/12/2013 6:11 PM (GMT-06:00)
>     To: Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>     Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto: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
>     <mailto: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>
>         > <mailto: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>
>         >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>         <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>         >     Unsubscribe : https://launchpad.net/~kicad-developers
>         >     More help   : https://help.launchpad.net/ListHelp
>         >
>         >
> 
> 
>