Re: gEDA-dev: footprint cleanup

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

On Tue, 2006-08-29 at 11:44 +0200, Igor2 wrote:
> On Tue, 29 Aug 2006, Peter TB Brett wrote:
> 
> <snip>
> 
> >I agree that the way the PCB footprint libraries work at the moment are really 
> >pretty impenetrable and user-unfriendly.  But *please* don't throw the baby 
> >out with the bathwater!
> >
> >Peter
> 
> I agree. I think a beginner won't care whether it's m4 or not, the
> difference in the selector window is not that clear. And if he doesn't
> know, why would he care? 

This hits the problem squarely on the head. Most users will not
appreciate (or care) what the difference is, and for all intents and
purposes, it does not matter which they use. The only difference is when
making new footprints.

> I also like the idea that we don't have 10000 megabytes of footprint files
> which differ only in 2 bits from one another. Maybe because I don't have
> 160 GB disks :)
> 
> Maybe the best would be to have a HID or other _simple_ C api to separate
> the footprint loading and have the newlib and the m4 code in different
> directories, like the HIDs in hid/. This also would allow one to expand
> the footprint side easier (databases and whatevers).

This sounds like a nice way to handle things in the long term.

As all embeded footprints are in Newlib syntax, an external command,
HID, action or library backend which emits Newlib syntax is clearly
appropriate. It is of little imporance whether the backend which gets /
emits the newlib syntax is the "M4" executable, or a "cat" of a newlib
file.

What I wish to avoid in the medium to longer term, is the proliferation
of huge parts-libaries, where DIP8, DIP16, DIP40, etc... are all
enumerated, all width variations, different pad styles, etc. We must
avoid listing all DIL connectors in existance, with different spacings,
numberings, pin sizes.

I imagine traversing a footprint tree, finding "Through-hole"->"DIP",
and then seeing a list of options (pin count, spacings, etc...), such
that footprints can be used without saving the a generated file into a
library, exiting PCB, or whatever else might be required at present.

If gschem2pcb continues to use the M4 library as it exists now (as was
suggested in one post), we still have to distribute the M4 library, keep
it working, and this further difference will be yet another difficulty
for the user.

How it is implemented is unimportant for now. My fundamental
disagreement is the suggested requirement to have one newlib file for
every footprint I'll ever place. It becomes a major task to maintain.
Should a user submit a patch for one produced at "make dist" level, a
maintainer must then re-create the fix at the M4 or generator level.

What we should strive to have is a generator system where "DIP 8 100
300", or whatever, input as a footprint string, will produce the
required newlib code for the part we want. For users who prefer GUI when
not working in batch mode, the generator will provide a GUI to select
the options I want, piecing together the generator's input string.

M4 and the existing library provides such a capability. Other languages
and libraries can do just as capable a job. By all means hide M4 and the
backend from the user. Just _for goodness sake_, don't call it "oldlib",
"newlib", or "M4" when they have to come and instanciate or edit one! 

Whilst most users (if they do), will use the PCB gui and save a newlib
file, we should not remove the power and flexibility that the existing
solution provides. The very same users who struggle to generate
footprints in PCB will probably have equal or greater problem working
out where to install it in a library dir.


Regards

Peter Clifton.





_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev