kicad-developers team mailing list archive

[Werner Almesberger <werner@...>]

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 
> container.

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 
> code),
[...]
> 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.

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
time permits.

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
about ;-)

- Werner