X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Ironport-SBRS: None
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2GKBQBJQbRV/52AA4BcgxWBPahyBAEBBQGBBZlqAoE2PBABAQEBAQEBA4EHhCQBAQQ6TwsYCRMSDwUNPBMZiAADEgXJfg2FLwEBCAIghh+FL4JOgVVrgxiBFAWNNoczileBaIFHhy+JB4crJoQdHjGCTAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,545,1432623600"; 
   d="scan'208";a="96456726"
Date: Sat, 25 Jul 2015 19:14:35 -0700
From: Larry Doolittle <ldoolitt AT recycle DOT lbl DOT gov>
To: "Jason White (whitewaterssoftwareinfo AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] [pcb-rnd] Release 1.0.1
Message-ID: <20150726021435.GA31176@recycle.lbl.gov>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1507251158120 DOT 6924 AT igor2priv>
 <CAOFvGD4TDEWGTvOF=mfzsQA1WDVL_qaZ4wjqRtLd9Pe5=qX4Pg AT mail DOT gmail DOT com>
 <mp0mkj$jq2$1 AT ger DOT gmane DOT org>
 <CAOFvGD4etQbqLE5X9qYAZ202X70jAQAd4zPpg2VUOUW7u=Zdsw AT mail DOT gmail DOT com>
 <mp1804$851$1 AT ger DOT gmane DOT org>
 <CAOFvGD5KcLXQt=bw2B1wDHRot4yQ0TFniYbjaJMZjo9-HjOVWw AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOFvGD5KcLXQt=bw2B1wDHRot4yQ0TFniYbjaJMZjo9-HjOVWw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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?