| Thread Previous • Date Previous • Date Next • Thread Next |
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 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.
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 possible.
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 the fly.
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.
Dick
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
| Thread Previous • Date Previous • Date Next • Thread Next |
