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: 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]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=089e01176aabde6565052856d9bb 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 --089e01176aabde6565052856d9bb Content-Type: text/plain; charset=UTF-8 On 2 Jan 2016 09:18, 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


On 2 Jan 2016 09:18, <karl AT aspodata.= 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 slig= htly 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 separa= tion of libraries and ui programs is good. It just depends on logical separ= ation, 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 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.

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't s= ee 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.<= /p>

Peter

--089e01176aabde6565052856d9bb--