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=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=X7HxtCjmgXZelbfvXsECspdRgrJOyTppzj/WblNVQ9c=;
        b=jiODBU33XrqQi4Y+BT1Sj40GguxFrztES9qEfkGizdlJhMX7qf/SAybSDjZKv/+zjL
         2/wCdxQCuPswF0GIoCoFNRJt6qZrNndfAfDfWeICQwpz/1KAzJ1rON3qBe1yRVog6JDn
         YLtO23WN/7cVvKfsikAyIF8txLvI65/stxV3C84BQD4nFeZTsSUTRl5bUfqBx8V+HV+o
         S4Do2Sk4IjstEPKGRWD84/XNRfW9keUJxklaZf6rofIS/Ay/EGL7LOSNWHGjOJfzmSAf
         LvaRVhy2M6iO5/RMupdwOgrHEMlh+Z+JXYKj9dl2Lmo6z2mRk+wqGKEiB4cYUxfZJE2M
         07MA==
MIME-Version: 1.0
X-Received: by 10.25.153.130 with SMTP id b124mr12658268lfe.81.1451762170172;
 Sat, 02 Jan 2016 11:16:10 -0800 (PST)
In-Reply-To: <CAJXU7q_Zwyfpcb4g00QCFNTjQ9Le2Tm8WjKz3CKMnNXb7gMceg@mail.gmail.com>
References: <20160102091556 DOT BBC6D809D79B AT turkos DOT aspodata DOT se>
	<CAJXU7q_Zwyfpcb4g00QCFNTjQ9Le2Tm8WjKz3CKMnNXb7gMceg AT mail DOT gmail DOT com>
Date: Sat, 2 Jan 2016 19:16:10 +0000
Message-ID: <CAM2RGhRpaokjQNvXzw01YcmZy4iuzd_ebR84p+FA_Bznoyh-+w@mail.gmail.com>
Subject: Re: [geda-user] should we broaden scope of libgeda
From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA users mailing list <geda-user AT delorie DOT com>
Content-Type: text/plain; charset=UTF-8
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 Sat, Jan 2, 2016 at 9:52 AM, Peter Clifton
(petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]
<geda-user AT delorie DOT com> wrote:
>
> 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.

I agree 100%. There are other things I would like to do with sch files
and it would be nice to render them in things other than gschem.
libgschem would make sense.

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

+1

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

+1
(Although I worry about the language choice for the plugin but I feel
bad even mentioning it)

> 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



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----