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
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

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

- Raw text -