Just for your information, Dick has worked on using Eagle libraries directly. The new eagle libraries are in XML and that makes editing easy. I am going to try to use that function. I already have some projects and footprints (and a full license for eagle version 5 but not 6) and do not want to do the work again.
Just my humble view. Greetings, Edwin On Mon, Nov 25, 2013 at 7:01 PM, Povilas Kanapickas <[email protected]>wrote: > Hello, > > One of the things that I noticed working with KiCad is that its cental > symbol/footprint library collection could be improved immensely. I'd > like to share several ideas that may (or may not) be useful. I'm also > willing to spend time implementing them, so hopefully the ideas that > will be deemed useful (if any) won't end up being forgotten due to lack > of time. > > Before I begin, please excuse me for being unfamiliar with any recent > developments, plans and decisions in this area. Even though I've read > the recent posts in the mailing list, there must be some things that I > misunderstood. > > Some of my ideas unfortunately conflict with the current direction of > the library sub-project. Please do not take any of them as a suggestion > that the current work should be dropped -- I only want to share my > optimistic and thus necessarily naive view of how the central library > collection could look like in the ideal world :-) > > > I think a central, official collection with huge collection of symbols > and footprints is necessary for KiCad. The reasons are as follows: > > * It's possible to provide at least some guarantees for the quality of > content. The user does not need to spend time verifying the data. > * It becomes the go-to place for symbols and footprints. Users spend > less time searching for them. > * The chance of duplication of work is reduced. > * (see the second point below for a specific model and more reasons) > > The main issue with the current approach is that the central library > repository is not 'accessible' enough to outside contributions. By > 'accessible', I mean plenty of things that hinder movement of symbols, > footprints and their improvements from third party repositories to the > central repository. If we want the central repository to succeed, this > issue is critical. > > Below comes an unsorted list of what I think could be improved in order > to solve the above problem. > > --- > > 1) Make the central footprint repository discoverable > > Currently is pretty impossible to find the central repository. > Unfortunately it's not described as 'official' anywhere, thus even if an > user finds it, he probably doesn't think this is the place to merge your > new footprints or symbols. > > The current situation could be improved by the following changes: > > * Add a link to the central library repository to > https://launchpad.net/kicad. Describe that repository as 'official KiCad > footprint and symbol repository' and say that contributions are welcome. > > * Do the above at kicad-pcb.org > > * Improve the currently inexistent description of the central > repository. Say that it's 'official KiCad footprint and symbol > repository' and say that contributions are welcome. > > --- > > 2) Make the VCS workflow intuitive and familiar to as many users and > developers as possible. > > I think the Launchpad workflow is quite unintuitive to the majority of > potential committers. For example, > https://code.launchpad.net/~kicad-lib-committers/kicad/library shows > only how to checkout the library locally. If you want to make your first > public repo you need to do some Googling on how to set up SSH keys, etc. > as no documentation is provided when you need it, e.g. whet you do bzr > push. > > On the other hand, for example on Github once you register you can push > almost immediately -- it's a bit inconvenient as it asks for your > password each time (until you configure password caching), but it works. > > Also, I think moving to git might be a good idea as many more people are > familiar to git than to bzr. > > Git also has a huge advantage in that allows single person to manage > huge repositories (see the Linux kernel for example). The > responsibilities can be offloaded to secondary maintainers with their > own trees, so the main maintainer does not need to bother at all when a > minor fix needs to be merged. > > This also means that it's sensible to collect even small libraries to > the central repository. The library maintainers could then fork the > central repository to their own trees, maintain their libraries there > and issue pull requests when they think their work is ready. > > Furthermore, this approach makes updating symbols and footprints an easy > task. One only needs to pull a single git repository instead of many. > > Finally, a single repository allows to enforce some kind of consistency. > I guess none of us want to work with similar components that are marked > differently :-) > > --- > > 3) Make merging easier and less complex. > > Currently a library corresponds a file. This is a bit inconvenient as > one can't immediately see what components are within that library. Also, > merging becomes more complex as one needs to use external tools to make > sure no duplicates are introduced. > > I think this situation could be improved if we introduced (I'm willing > to work on this) a library format that makes a library to correspond to > a directory (plus an index file) and each of the components to a file > within that directory. This would allow to immediately see what > components does a library include without any external tools. This would > also make merging easier -- the chance of conflicts and inadvertent > duplications would be reduced to a minimum. > > --- > > This is all I have to say for now. It would be get some feedback even if > my ideas seem silly or conflicting with the current goals -- I'm willing > to work on improving KiCad, so it would be great reconcile the > difference of opinions from the start :-) > > Regards, > Povilas Kanapickas > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
