Mail Archives: geda-user/2015/07/25/22:14:54
Jason et al. -
Surely we are all in violent agreement here. Having a general, "standard"
scripting way of creating footprints is good. Parameter databases are good
(gently ignoring the question of flat-file vs. XML vs. programmatic database).
Having that mechanism available at runtime is good. Having that mechanism
available at compile-time is good. Pre-computing files we guess are commonly
used when creating binary distributions/installers is good, since it absolves
casual users of some of the questions about version sensitivity of dependencies.
I would add a couple more wishes:
1. Footprint files so generated are clearly marked as such, with embedded
information about how to reproduce them (especially the parameter values
that went into the script, and maybe some version information about the
script itself, but not the time or username of the script running itself).
2. At install time, spot-check if the available tools can reproduce
some "gold" footprint files, and if not, give a warning and/or disable
script options in the menus.
3. I've learned to like a database-ish mechanism where a footprint named
foo can be defined to be "just like" or "a copy of" bar, except with a
specified parameter changed (and new value provided). In combination with
(1), I think this is the lowest barrier to a user tweaking a nearly-OK
footprint for real-life use.
- Larry
[sorry about the top post, but it seemed appropriate in this case]
On Sat, Jul 25, 2015 at 09:01:51PM -0400, Jason White (whitewaterssoftwareinfo AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> > Algorithmic footprint creation on the fly moves footprint creation out
> > of the immediate realm of the user. This makes it even less
> > accessible.
> I suspect you have a different definition of accessible than I. This
> (parametric footprints, inside pcb-rnd) is available here and today;
> its easier to use than digging drawing a symbol from scratch every
> time. It provides an excellent starting point for users to make their
> own custom footprints. Remember, parametric footprints can be saved
> and modified just like normal footprints.
>
> If you think users will use it as a crutch, you are right! That
> indicates something quite important, the footprint creation process is
> not intuitive. A new user must read the documentation if they want to
> make (or use) a custom footprint, period. The way things are set up
> in PCB, the user stand little chance of figuring it out how to do it
> by themselves.
>
> > All of this is is also achieved by algorithmic creation at build time. [As opposed to doing it in t]
>
> Why *only* at build time? Would you have the user recompile PCB each
> time they want a new parametric footprint?
>
> Surely it has occurred to you that Igor2's parametric footprint
> mechanism could be used around compile time to generate the standard
> library, right?
- Raw text -