kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Any sign of someone showing the notion of ownership or stewardship in the libraries seems
positive to me.  So thank you.  I hope that folks more knowledgeable than me about
libraries will answer your email, and thereby reward your interest and investment in time
with a better answer.


IMO, a large part of the usefulness (utility) of the libraries hinges on how easy it is to
find something when you are looking for it.  Generally these days, when I want to find
something, I often use google.


This is why I've been working towards:

a) *.kicad_pcb file extension.

b) *.kicad_mod extension for pretty footprints.

c) Large, potentially extremely long winded comments at the front of the pretty footprints
which are simply carried through or ignored by pcbnew when loaded as a footprint (not
nested in a board).

d) having footprints potentially get scanned by google's crawler, along with the
unambiguous filename extension, *.kicad_mod, to facilitate searching in google.  And
hopefully the long winded comments will get indexed as well.  So that some day you can
search for


  kicad_mod  "blah blah"


I use google a lot.

But I am not a library expert, so I cannot help you further.


Dick





On 08/25/2013 02:57 AM, Kerusey Karyu wrote:
> Hello.
> 
> I would like to split the atmel.lib into several smaller libraries. This 
> would be a similar division to the families which already exists in the 
> Microchip MCU libraries.
> 
> My proposals are as follows:
>   - atmel_avrlegacymcu.lib - where the symbols of Classic AVR family 
> have been moved
>   - atmel_avrtinymcu.lib - where the symbols of AVR Tiny family have 
> been moved
>   - atmel_avrmegamcu.lib - where the symbols of AVR Mega family have 
> been moved
>   - atmel_51mcu.lib - where the symbols of Atmel’s MCS-51 family have 
> been moved
>   - atmel_avrxmegamcu.lib - where the symbols of AVR Xmega family have 
> been moved
> 
> Later this same method can be used to create specific libraries for 
> other processors families, like: SAM3, SAM4, SAMD20 (new Atmel’s Cortex 
> M0+ devices), UC32 or many other non-MCU devices: memories, touch 
> sensors, RF, etc.
> 
> After the library split, atmel.lib could be removed to avoid duplicates. 
> However, backward compatibility problems may face in the way in the 
> existing users projects. (I can already see the tons of messages “Where 
> is my library?” on the user mailing list.)
> 
> 
> Since this is a big change and may have some sort of influences, first I 
> would like to know the opinion of developers and eventual 
> acceptance/permission of those changes. Including the removal of atmel.lib.
> 
> 
> Regards
> Kerusey Karyu
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>