← Back to team overview

kicad-developers team mailing list archive

Re: where footprints come from (was Re: Re: Internal

 

Werner Almesberger wrote:
Dick Hollenbeck wrote:

Multiple origins of libraries is what we have now. The process to download, install and what not goes away with a proper API.


Okay. If we include the conversion from the real source to the
intermediate format in the set of operations the things beyond
the API perform, then that part is indeed transparent, and what's
left is a packaging issue.


As soon as a download is done, there is a disconnect between the library maintainer and the downloaded copy.


That's not so good, but I think this restriction would be easy to
eliminate, e.g., by having one or more "edit" operations at the
API.


I was assuming the public library had a person maintaining the library on his website. When he makes changes, you don't get them if you've previously done a download and install. With the footprint library plug-in for such library, which physically exists on his website, you never make a copy of the library, you grab the part from his website. I don't agree about the edit functionality in the API.


What would be the general design of that API ? Something like NFS
where you have an opaque token that more or less represents a
pointer to an inode ? So you could

next_inode = change_directory(old_inode, dir_name);
fd = open_file(inode);

and so on.


C++

plugin->DoSomething()



I am not volunteering to enhance the module editor, other than to teach it how to use the API.


Fair enough. So, how do we solve the problem that the default - and
implicitly recommended - editor lacks functionality many people
would consider essential for getting the job done then ?


Hope that among the persons most bothered by it have some C++ experience and can contribute enhancements.

Or that they can at least make suggestions to my basic
(footprint .....) file format proposed 3 weeks ago, and have those available by April.

Change the editor, change the default, change the job ? ;-)


Plugins would be C++ DLL's on windows, or DSOs on *nix. They can make http requests, DBUS requests, ftp requests, nobody cares. They should be cross platform however.

If the types used at the API are simple enough, it should also be
easy to make all sorts of language bindings. Even shell might be
an option, albeit favouring certain platforms :-)

If you go back and look at my postings, I switched from structures to strings in my postings. The retrieval of a part can be done by returning a [multi-line] "(footprint....)" string.

This is also what I want to use on the clipboard.


And I hope somebody like Texas Instruments is reading this, because this is an opportunity for part vendors to distinguish themselves from their competitors. They should be maintaining a footprint library for their parts. Why do we have to do it all? Digikey? Whoever.


Hmm, I wouldn't expect this to happen anytime soon, particularly
not from large companies like TI. I think it's a safer bet for
us to make it convenient to maintain our own component libraries.



No, not without a plug-in API and sample code on how to write one. But with one, and with an ever expanding Kicad user base, it is not beyond the realm of possibilities that somebody writes such a thing.


Dick








Follow ups

References