X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-UW-Orig-Sender: fpm AT homer03 DOT u DOT washington DOT edu
Date: Fri, 23 Sep 2016 08:10:33 -0700 (PDT)
From: "Frank Miles (fpm AT u DOT washington DOT edu) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: Roland Lutz <rlutz AT hedmen DOT org>
cc: geda-user AT delorie DOT com
Subject: Re: [geda-user] Possible paths of gnetlist development
In-Reply-To: <alpine.DEB.2.11.1609221743230.2817@nimbus>
Message-ID: <alpine.LRH.2.01.1609230805300.4835@homer03.u.washington.edu>
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1609221743230 DOT 2817 AT nimbus>
User-Agent: Alpine 2.01 (LRH 1217 2009-02-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.23.145717
X-PMX-Server: mxout21.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report='
 HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0'
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

On Thu, 22 Sep 2016, Roland Lutz wrote:

> With the refactored code, some of the features which have been on the 
> wishlist for gnetlist for quite some time but require more fundamental 
> changes to the code have become much easier to implement (or feasible at 
> all).  Since Igor2's approach seems to have been somewhat successful, I'm 
> proposing the potential paths of development for gnetlist in the form of a 
> "poll"; please let me know in which of the options you are interested or 
> which you would like to use on a regular basis.
>
>
> 1.) More control over the netlisting stages

of course

> 2.) Saving a generated netlist in an intermediate format

possibly

> 3.) Proper parameter substitution

yes

> 4.) A netlister GUI

not interested

--------------

* How does DRC work with these?
* Would #2 allow on-the-fly schematic alteration, perhaps for multiple-format
 	netlisting (spice, kicad,...)?
* Would #3 be interoperable with a part database?  So that a DB-key could be
 	inserted into the schematic, but that more detailed part information
 	could be available to subsequent BOM generation and the like?

Thanks for all your work!
 	-F