kicad-developers team mailing list archive

[Dick Hollenbeck <dick@...>]

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