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:from:date:message-id:subject:to
	:content-transfer-encoding;
	bh=gvxWO9nboyUBcomY/O7YIjcupnaS/iTh3zGr8cJt9sU=;
	b=oE6suZo84wZZ3XDCoo9V2J4Zgn+oRVFeZDu95hAYzE2PmxL+f5L1J+3D5IwOPkSuLy
	vJJ3geT29DmmdnjrWRKc1zzgmvpBNMBt31inPHSz+ATpMCR9aoVGOdsxQccLmaSmlCKA
	Ih3xkhOJvhj1bGvjJYjUHGMgrjd1kjdY65tQGfaZSejBUGncPIx72yzrY/z8V50GPCJc
	qivb3Y1pNTqWnE4G1jIVa+gQhRHSEBuULqd3VmpnTtzFqZiM7etIX1aqkChUK7v7Yq6F
	DZeG6U5uYQM/fygG4IcR6nEap3sh4FkWAUHWiXnzl6YUOpgjnCVRkOxw51eJEG5O8FOt
	pvKg==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-transfer-encoding;
	bh=gvxWO9nboyUBcomY/O7YIjcupnaS/iTh3zGr8cJt9sU=;
	b=d4CLv7EejwlLFdtmwL5KyCBhLptXdRkYwIl7KPCI+x9NplDF7YDsceEHvkII9+qtcc
	Xk273SZaRltrgDHWimy1j+1dtc0X9+UmF6Eittn7HaDoT6tP52RHQUXTUVY7iaO1ZtVQ
	fXBZN0etRlMjZeZJLEA+dL6Ck70KsH//h+KiZX/9nvz1Nf9uWXEcpVUFlnVY1qjejzqV
	3L97F4VnKIimkqHvlZo2fJIVkVKRn2ngNYbUBgdquQFhzy/BiqQF1G/xGoH8lzcC9s6A
	e2FhIBEPwsk212Ai/O+DHd1enTOjBWEMjGkD7w89i4I2YhnhRGqh9v7yGJLXc3s6+e42
	vnWQ==
X-Gm-Message-State:	AEkoouuOKnHvKCsDalroUDRy5QsZgzgziSiV+Ux5ZY8TMXOy2p28TRUZC6wpNI1AYhJUjqQlmtxQEkmdd8Zo/A==
X-Received:	by 10.25.201.203 with SMTP id z194mr17300844lff.192.1470153634466;
	Tue, 02 Aug 2016 09:00:34 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.11.1608021426490.1398@nimbus>
References:	<CANqhZFwC48g07MUY411a20C5oipkmmkzUimhz8OgvL2Thi-yDg AT mail DOT gmail DOT com>
	<20160722171754 DOT GB17595 AT localhost DOT localdomain> <CAM2RGhRjABmejtuSz1PbGFFF+EHhznGGTODoh0bu2y4FJM=Cbw AT mail DOT gmail DOT com>
	<20160723065723 DOT GC17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 00 DOT 1607231009290 DOT 7286 AT igor2priv>
	<20160723092248 DOT GF17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607231423480 DOT 2224 AT nimbus>
	<20160724053502 DOT GM17595 AT localhost DOT localdomain> <alpine DOT DEB DOT 2 DOT 11 DOT 1607271434200 DOT 1841 AT nimbus>
	<9719FF2C-AC85-4824-89E9-447216E7FA65 AT sbcglobal DOT net> <alpine DOT DEB DOT 2 DOT 11 DOT 1607301258260 DOT 1409 AT nimbus>
	<939E39F7-B4DA-4B56-A640-C7E6E4ECF955 AT sbcglobal DOT net> <alpine DOT DEB DOT 2 DOT 11 DOT 1608021426490 DOT 1398 AT nimbus>
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Tue, 2 Aug 2016 12:00:33 -0400
Message-ID:	<CAM2RGhQH85yMBavvYO1J7TKUrQ16jLGjmbDmAVOxvekyzk+yyA@mail.gmail.com>
Subject:	Re: [geda-user] Plans for gEDA/gaf (was: [OT] ngspice integration in KiCad)
To:	gEDA users mailing list <geda-user AT delorie DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u72G0ea5009610
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 Tue, Aug 2, 2016 at 9:19 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
> On Mon, 1 Aug 2016, Edward Hennessy (ehennes AT sbcglobal DOT net) [via
> geda-user AT delorie DOT com] wrote:
>>
>> Let’s call this new library "libcore" for clarity in discussion, and
>> “libgeda” for the existing legacy library.
>>
>> Does you vision of libcore support any of the following?
>>
>> 1. GObjectIntrospection and GIR files for language bindings?
>
>
> No.  The core library should not know about GObjects in any way.  Of course,
> it would be possible to create a GObject wrapper for the core library which
> could be used for creating language bindings.
>
>> 2. Weak references to basic objects?
>
>
> No.  The objects would be either simple data structures or pointers to
> opaque types.
>
>> 3. Property change notifications of some sort? (gobject signals,
>> listener/observer patterns, etc...)
>
>
> No.  The library would use a value-oriented approach: the properties of a
> schematic object are only defined in respect to a given revision.  If an
> application needed property change hooks, it could execute them itself from
> the command which replaces its current revision with a new one.
>
>> In regards to merging back into gschem, do you see gschem as the schematic
>> editor going forward?
>
>
> Originally, I started out writing my own editing GUI which was indended as a
> replacement for both gschem and PCB.  This is not realistically going to
> happen any time soon, though, so I'd suggest sticking with gschem.
>
>> If gschem is the editor going forward, I’d like to see:
>>
>> 1. GUI widgets moved out of gschem into a separate library, “libgschem,”
>> which could be renamed from libedacairo.
>
>
> I'm not sure what's your point here.  Do you want to facilitate using gschem
> widgets in other GTK applications?  The actual Cairo rendering code may be
> useful to non-GTK or even non-interactive applications.

There is a serious value to being able to render schematics in other
applications. Someone here did a filter designing tool a while back
that called gschem but with this added library you could embed
schematics in other things.

>> 2. Migrate to GTK+3
>
>
> That would mean losing multi-stroke hotkeys (as discussed in the past).
> Migrating to an even more recent GTK would mean losing tear-off menus.
>
>> 3. Potentially use a more productive language for gschem and libgschem,
>> like Vala or C#.
>
>
> C# uses the .NET framework, which would theoretically be an option via Mono,
> but its political fate is uncertain.  By using Vala, we'd lock in even more
> than by using Scheme.
>
> The options are really quite limited here.  I think it would be best to
> stick with C for the existing schematic editor, but C++ or an interpreted
> language may be an option for a future project.
>
>> What are your thoughts on a clean restart on the UI?
>
>
> I already started such a project: http://hedmen.org/xi/
>
> The problem is that this requires a non-trivial amount of work.  I've been
> working on Xi for a few years, and there's still a lot to do.
>
>> I agree with you on the Guile dependency, but suspect it could be removed
>> with a dependency inversion. In essence, “libcore” or “libgeda” would know
>> about scripting, but it wouldn’t know that it is Guile, Python, or whatever.
>> This pattern might also be applied to rendering too.
>
>
> Why would the core library need to know about scripting?

IMHO scripting should be a thing the user can install optionally at
run time. That way packaging people at the distro level don't have to
think about it. We don't create weird dependencies like guile. gEDA is
literally the only thing on my boxs that use guile. It also ends the
fight over who's language is best.

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

- Raw text -