X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=0kEmfES8V1Y2a1aZNhtowYDCzsY+MFWVr0xFNkkSI90=;
	b=q0p9K9gT6zWwUeNp/sG9Hi5MvMazQo2Z5t2znF/ea2GmXYjGaa+NXmT29X9vmsRKiB
	lFKabjDDyjD+iRLfd7cPoq+VkqrjsumJKKwJcDGPvorWbTVFOGY+ds+8HrEfzjLFBRQC
	G5DLXWyOxW7gh3xvKhx4n4en8MbxmGaAJkxbiPcmZuJjD0TCMVfr7eCEuuhUBSyVlJZV
	K3z36BTSuR0ttVQ18BA5pchrAwT7qT1UdhgXstEAbrzv+1B1IFPEMH09NZDxw7Rtf3un
	9DJnmSDjbVyu45rPFDYdDkCk+kePcdVZB/2y3cSQRux2tegb7JafLxQ/ksRPI6sGcbo1
	eKnA==
MIME-Version:	1.0
X-Received:	by 10.60.97.2 with SMTP id dw2mr52295646oeb.40.1451728371079; Sat,
	02 Jan 2016 01:52:51 -0800 (PST)
In-Reply-To:	<20160102091556.BBC6D809D79B@turkos.aspodata.se>
References:	<20160102091556 DOT BBC6D809D79B AT turkos DOT aspodata DOT se>
Date:	Sat, 2 Jan 2016 09:52:51 +0000
Message-ID:	<CAJXU7q_Zwyfpcb4g00QCFNTjQ9Le2Tm8WjKz3CKMnNXb7gMceg@mail.gmail.com>
Subject:	Re: [geda-user] should we broaden scope of libgeda
From:	"Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	gEDA User Mailing List <geda-user AT delorie DOT com>
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

--089e01176aabde6565052856d9bb
Content-Type: text/plain; charset=UTF-8

On 2 Jan 2016 09:18, <karl AT aspodata DOT se> wrote:
>

> Wouldn't it make sense to move things (that isn't related to a gui)
> from gschem to libgeda ?

I would have said not.... unless we are talking of specific things, moved
with good reason. There might be some argument for creating a libgschem
though, which might draw from both.

The boundary between gschem and libgeda has always been slightly odd in
some cases - so whilst I'd concede there might be cases for moving certain
code one way or the other, I think a more formalised separation of
libraries and ui programs is good. It just depends on logical separation,
and potential reuse cases.

For my point of view, moving some of the low level code from gnetlist, into
libgeda makes sense. It could start to allow a framework where we use
plugins that apply some of the semantic attribute meanings at a point
shared between the tools. (Meaning you can have smarter behaviours in
gschem whilst those workflow specific plugins are loaded). I would love to
see things like slotting move to being a plugin, for example.

gnetlist should continue to function and look the same to the outside
world, but code wise - may end up much simpler, probably just providing an
invocation wrapper around the backend scheme code. Some backends which
apply meanings to attributes in a way that influences the netlist might
usefully split into workflow plugin + netlist backend, but I don't see any
reason why general back end code would have to change (compatibility should
be easy to maintain).

Just my thoughts - since I'm currently focusing on pcb.

Peter

--089e01176aabde6565052856d9bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 2 Jan 2016 09:18, &lt;<a href=3D"mailto:karl AT aspodata DOT se">karl AT aspodata.=
se</a>&gt; wrote:<br>
&gt;</p>
<p dir=3D"ltr">&gt; Wouldn&#39;t it make sense to move things (that isn&#39=
;t related to a gui)<br>
&gt; from gschem to libgeda ?</p>
<p dir=3D"ltr">I would have said not.... unless we are talking of specific =
things, moved with good reason. There might be some argument for creating a=
 libgschem though, which might draw from both.</p>
<p dir=3D"ltr">The boundary between gschem and libgeda has always been slig=
htly odd in some cases - so whilst I&#39;d concede there might be cases for=
 moving certain code one way or the other, I think a more formalised separa=
tion of libraries and ui programs is good. It just depends on logical separ=
ation, and potential reuse cases.</p>
<p dir=3D"ltr">For my point of view, moving some of the low level code from=
 gnetlist, into libgeda makes sense. It could start to allow a framework wh=
ere we use plugins that apply some of the semantic attribute meanings at a =
point shared between the tools. (Meaning you can have smarter behaviours in=
 gschem whilst those workflow specific plugins are loaded). I would love to=
 see things like slotting move to being a plugin, for example.</p>
<p dir=3D"ltr">gnetlist should continue to function and look the same to th=
e outside world, but code wise - may end up much simpler, probably just pro=
viding an invocation wrapper around the backend scheme code. Some backends =
which apply meanings to attributes in a way that influences the netlist mig=
ht usefully split into workflow plugin + netlist backend, but I don&#39;t s=
ee any reason why general back end code would have to change (compatibility=
 should be easy to maintain).</p>
<p dir=3D"ltr">Just my thoughts - since I&#39;m currently focusing on pcb.<=
/p>
<p dir=3D"ltr">Peter</p>

--089e01176aabde6565052856d9bb--

- Raw text -