kicad-developers team mailing list archive
Mailing list archive
Re: where footprints come from (was Re: Re: Internal
Dick Hollenbeck <dick@...>
Tue, 22 Dec 2009 00:36:51 -0600
Thunderbird 220.127.116.11 (X11/20090817)
Werner Almesberger wrote:
Dick Hollenbeck wrote:
The external tool for footprint editing would be more practical if each
footprint was in a separate file. I have supported this for some time,
even in the face of disagreement from others. The notion of a footprint
library can easily be done by using file system directories as the
Yes, I wholeheartedly agree. I always found having these
containers on top of the file system a distraction at best.
I have said before that if such an API is defined, (and this could be
done using a *.h file and Doxygen without writing one line of actual
Although we could also use a text string for passing some of this, using
a format similar to what we have been talking about here, and also in
the context of smart clipboard pasting.
I guess it depends on what you're looking for. If you want to support
multiple file formats, then the "fat" API is better. If you just want
multiple library interfaces, a file for the final positions works as
well, and may be easier to interface with.
Multiple origins of libraries is what we have now. The process to
download, install and what not goes away with a proper API. As soon as
a download is done, there is a disconnect between the library maintainer
and the downloaded copy. I am not intimidated by an API, and I feel
that I can contribute this and make it very simple in a few months. So
I am volunteering to do it, if folks can wait a few months. This is a
footprint library API intended for implementation within multiple
simultaneously active plugins. I have coded tons of plugin
architectures over the years and know tricks to keep this as simple as
With a proper API, the conversion programs, the perls, the pythons, and
maintainer's tools are all unimportant and remain hidden behind the
plugin. The API has to support a) searching, b) configuration, and c)
fetching, but not footprint editing directly (but see below about
copying). The plugins will convert data from other flavors to a common
serialized string format like our contemplated lisp-like (clipboard
compatible) format. This would mean that a person could build a bridge
from almost any library "file format" or "source". The API would allow
you to read a string describing a footprint, and that string could come
from an http:// request from Texas Instrument's website, or from a DBUS
bridge to a Python program. The string returned describes the footprint
in the simplest form that we need, and could be a significant reduction
from the "file format" that the part is actually stored in. So folks
could continue to maintain footprints in PERL, nobody would care.
The footprint format is to be spelled out as part of the API, and is a
clipboard compatible string. The stock module editor becomes a client
of the API, and could fetch a footprint by API, edit it, and save it to
your personal library in modified form.
More than this I am not volunteering for.
And all of this should not be expected from me before April or May or
so. Comments, samples, and examples of the lisp-like footprint file
format are welcome. I do not claim to have all the answers there, yet.
But putting in unnecessary baggage which is useful only to some origin
of a library is something I would resist, because the plugin for such an
library origin should and could have as its responsibility to strip out
this information. In fact, as said before, the origin of the library
can be chipmonks maintaining the library chipmonk format. The chipmonk
plugin does on the fly lisp-like string generation so it returns an in
memory string format that fulfills the requirements of the API.
I am not volunteering to enhance the module editor, other than to teach
it how to use the API. Part of using the API is to is to fetch
footprint strings. The code to parse the footprint string is my
DSNLEXER and suitable recursive descent parser on top. This is also
code which can be used to implement a very rich copy and paste to clipboard.
The editor for foreign footprint libraries can be anything, and this
means that fped would not have to change one iota. Others might use
python or zsh or perl. The simplest plugin would be one that simply
loads footprints from disk and does not have to convert them at all in
RAM because the format used on disk is identical to the format required
by the API. This sounds like a series of fgets() with concatonation,
building up a complete footprint string before returning it to the API
client. The source code to this simplest plugin would be available as
an example. Another plugin would on the fly convert from geda, I
believe this code is already in pcbnew, but it should go into a plugin
under this design. More complicated plugins can use my STRINGFORMATTER
to build up a footprint string before returning it to the API client, on
If there is wide spread resistance to this direction, I am not offended
if it were to be voiced. But as I said before, since this is all
volunteer work, it is difficult to control the results of the work
unless you are actually doing it.
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.
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.
But, while properly abstracted interface are certainly good
development practice, all of this wouldn't necessarily help towards
having a common high-level language.
Also, I don't think we really need many parallel mechanisms for
making footprints. As long as we have one that's powerful enough,
there would be little reason for people to use something else, and
sharing footprints across projects would be so much easier.
Obviously, in the absence of a suitable common solution, everyone
will come up with their own, with the usual results. In fact, if
my eyes don't betray me, it seems that we have a small language
war brewing already ;-)
So I would still like to find a strategy for eventually having a
stronger "standard" footprint editor.
If you like the general direction in which fped it going, perhaps
we could try to come up with suitable extensions to the new file
format to express the "new" constructs. I could then make fped use
this format as its native format so that we have a full proof of
concept. KiCad itself would initially only need to be able to read
the new constructs, but editing capabilities could be added as
Of course, I would also like to know what Jean-Pierre thinks of
all this. After all, it's "his baby" whose future we're talking