Thread Previous • Date Previous • Date Next • Thread Next |
Vesa Solonen wrote:
Dick Hollenbeck kirjoitti:phinitnan_c wrote:Hello, I've created a set of library/package/3d and would like to share withthe group. How can i do that? I also think that it would be good if there is a center repository for the library and make the lirary easier to share.My guess is that we all like to get this sorted, but I'm going to try persuade everyone to wait a bit. Why? Because the infrastructure is not ready yet. Current library system is IMO too limited for multiple reasons and I have to make a document similar to Dick's notes_about_pcbnew_new_file_format.odt found in KiCad SVN root, but regarding symbol-component library. Most of all, we haven't yet agreed on symbol styling and naming rules. I've done some proposals about the style and they were generally accepted (no strong opposition, so I take them accepted...). Feel free to correct. Footprint naming was discussed some time ago, but decisions were left somewhat open.
Vesa & Jean-Pierre,I am happy to use the term 'footprint'. That says something. A certain amount on consistency on choice of nouns will make these conversations easier to follow.
As I said before, I hope to contribute a footprint retrieval plugin architecture starting in March/April time frame.
What might fall out of that, hopefully, is the ability to have a globally unique identifier for a footprint. I am not talking about eeschema symbols here. The globally unique footprint identifier will consist of various parts, TBD. But we could imagine that we might need to include what follows.
Generally what I am thinking is, WRT a globally unique footprint identifier, that it would have at least these fields in the identifier:
A) plugin name, B) library locator (syntax could be plugin defined) C) footprint name D) revisionA concatenation of the above fields with syntactical separators, could then yield a single string which could be used to find a footprint anywhere in the world, at least if connected to the internet.
I have no interest in dictating anything here, especially not C). Actually I don't even want to be involved with C). But when you talk about "footprint names", I at least want to give you a sense of what that context is, down the road, just C).
Once you have a globally unique footprint identifier, then it will be possible to make associations from your EESCHEMA symbols to the footprints. AND folks will be able to have their own footprint libraries, as long as they can provide a plugin that offers access to them, privately or publicly. The entire notion of a central or master footprint library is probably obsolete at that point. There can be a "Kicad project team maintained" footprint library, but I expect there to be any number of other footprint libraries. Some from part vendors, others purely commercial and non-free.
We will likely need an internet based registry for the combination of A) and B).
Then the footprint plugin retrieval API will provide some simple directory (i.e. search) services once a pointer is established to the combination of A) & B)
I really don't have an interest in personally doing work beyond this, namely to the eeschema symbol infrastructure, but I do hope that some of the footprint retrieval API and plug-in architecture could be reused and refined for that end, once the power and use cases are all better understood.
I do not want to hold up my work trying to munge together footprints and eeschema symbols. That munging needs to happen on the symbol end, not the footprint end. I am biting off what I can swallow, not more, do don't start talking about how the footprint library needs to have symbols in it. That is beyond my commitment.
Others can come in later and extend it.If this is all an obvious waste of time, let me know. Otherwise, you'll see more from me in March/April on it.
Dick
I'm sure you understand that we cannot allow just anyone to slam stuff into the master library repo. Such a thing does exist on SVN, and Vesa has been the maintainer of it. If you want stuff merged, send them to him.The maintainer seems a bit too honorable to me as I haven't yet written _anything_ to that repo :) JP did the last addition, but I'm willing to take the library lead if we reach consensus that I have enough credibility to be the benevolent dictator there. I think "newlib" directory gets added for that.Vesa if you don't want this hat, maybe its time to start recruiting help. We're going to have to have more defined roles to grow this project without chaos. I like that you stepped up and volunteered to wear a specific hat.I'm very happy to get a defined role as a project librarian, no doubts about it. Something to consider before a real library rework includes at least following: * Implementing one symbol to multiple component mapping http://tech.groups.yahoo.com/group/kicad-devel/message/3799 * Implementing pin and gate swapping * Logical to electrical to physical mapping some components don't have logical or electrical polarity, but only physical (variable capacitor) * Everything must be abstracted as much as possible to get flexibilty and ease of use and maintenance. * Is my style proposal good enough None of the above is not going to be fun or fast and I very probably end up being quite punctual regarding "libarary standards" because someones work depends on it (me included). That may also upset someone, but it won't be my intention. Be assured that I'll do my best to sort those possible upsets. So in the end phinitnan_c, I'm very willing to work with you on this. -Vesa
Thread Previous • Date Previous • Date Next • Thread Next |