X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-SourceIP:	95.97.163.245
X-Authenticated-Sender:	b DOT mykendevelopment AT upcmail DOT nl
Message-ID:	<55DCABA5.9070100@iae.nl>
Date:	Tue, 25 Aug 2015 19:53:41 +0200
From:	myken <myken AT iae DOT nl>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version:	1.0
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Re: off-topic: daydreaming about modularization
References:	<CAM2RGhTJ-gywb3LrkKoNKUxkwJCTsJ7vRxiLtmrXa5Mnp0331w AT mail DOT gmail DOT com> <DUB125-W46D6798DBF674B80F24208C6620 AT phx DOT gbl> <6B8DDCCF-0E84-43DC-94A3-89CE0E56F0ED AT noqsi DOT com> <201508242052 DOT 28189 DOT ad252 AT freeelectron DOT net> <alpine DOT DEB DOT 2 DOT 00 DOT 1508250534570 DOT 6924 AT igor2priv> <3766120C-93DD-454D-B2FA-7C79B78DC86C AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1508251403030 DOT 6924 AT igor2priv> <8DC5050C-49D2-49AD-94B0-A1FC857178E5 AT noqsi DOT com> <55DC6491 DOT 8030607 AT iae DOT nl> <3FA132D6-A8D9-47C8-8D37-E1962EF4098B AT noqsi DOT com> <55DC78F8 DOT 1010105 AT iae DOT nl> <CAM2RGhRYZ5Mxf8yUqsSmQ0Uzdb-4jc6-cSCKQ4kiMS6bOfEiHg AT mail DOT gmail DOT com> <55DC8B80 DOT 4020504 AT iae DOT nl> <CAM2RGhTD2MKKuXhK=tP7EwfrKuUBa7A0uCZF17LNx6+XQknwAg AT mail DOT gmail DOT com>
In-Reply-To:	<CAM2RGhTD2MKKuXhK=tP7EwfrKuUBa7A0uCZF17LNx6+XQknwAg@mail.gmail.com>
Reply-To:	geda-user AT delorie DOT com

On 25/08/15 18:42, Evan Foss (evanfoss AT gmail DOT com) [via 
geda-user AT delorie DOT com] wrote:
>> >Sound great to me. Anyone opposes this? Can we move forward from here?
> I think in that objectives thread a while back we agreed that adding
> other plugin interfaces in parallel to scheme was a good thing. The
> best way to do it would be via (gpmi) the same library Igor2 used in
> pcb-rnd. That way we don't add any additional dependencies and debug
> will be easier. One thing that would have to be worked out is how to
> block gpmi from passing scheme along since it also supports that
> language. We don't want to unintentionally gain an extra scheme
> interface (one is more than enough).

Maybe the way forward is working this plan out, in a separate project 
manager / navigation tool, and implement it into gschem if necessary or 
desirable when the stable working PM/NT is available.

- Raw text -