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=sbcglobal.net; s=s2048; t=1470153027; bh=pDRrCmR1b/ZxBg0RTpD0XyDk7WurR5BSuESQKJqEyP0=; h=Subject:From:In-Reply-To:Date:References:To:From:Subject; b=EYMC3hm1IDbjo1mZNGt/Yp+iPcCtJHhH1cVwCPCXwia8QMNol8qTUvR6HMIxhNR9CGA6hPzJBgbi9F7Si8UQMMEYSwEu+JJGwENLEL45m1FNxHtECasKCeeeRBBJqWpeqj/UvxFsp7+VojyJZ6CwYXCnyvD7VxK1C+4kcOHK6Xt8QErC+dDJKfV7Dqvo8tYbn49W8vaPs+NDXOKcM1trNnglkWCcKg5wAf6f2ASnwDJcnwEcQjeIcQhzfH4o6oWw2/A8fac9jn5SoOECSW2tzpNLDW2hf3U65fjJdMDXqkc/cy3SuATZX6rl3ywcxEAvUIH5jlI2d/61JvsCtJSBFg==
X-Yahoo-Newman-Id: 170795 DOT 62782 DOT bm AT smtp116 DOT sbc DOT mail DOT gq1 DOT yahoo DOT com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 0gv09QkVM1mLeQrtgjiSUd8cbC8hVBkPPZXsuB9obVTrNc5
 C31p5gqvo97Fu.pnHUYD51nvQ2Lh0.e.K8ftChu4lqW9i4moVZPVJ6SVUr.7
 oWFzb9JON5LxD4WIfatJLQMI3UeQv0FdAEyof1sGGsXxG4ypvyrQas2Cbg2S
 1ahUsw2CuNv3oFWrCcxKCYD9L0FG6NlQ3boFYwKIXjhGI2gVcJk6G7zA67Y8
 _c5vkaXFNLDCN5hYqcIdl5KOUF8eoWNDaQpUEBCFCJSwwIH8BzZ7BngOq7XL
 Y9UW7jYSFBWSkvIIKohMK.pSDrUss69Cdbi8j26XnQtDxRUP0Pn9bBF38dly
 q.jnHj93ba88hmKtw2ebqT.teK5sqiEZBAsOYlGXitdt6VfcWvIFjbXF7WdQ
 6_Bk6ZGChoIosiZ11AuBA82I1zhaake6Sn3Q3FYaZL3VKwoR8.Cmf0Qjk4v4
 ogxaodz0fUlyx97pEPN2lA6N55eXYjeGZZISoCIq3s1G0TExZSfuQzF8oNv0
 lWt1OAcKAQW5PpLUOnj4idhmXwpb1MMnGpZb8w58dmqXMCfiom3Cq99hBYxO
 l
X-Yahoo-SMTP: b8jVkbOswBAqZ4BhECp7nxPJUfTGEnEGv_G4qgQeZMeAbA--
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [geda-user] Plans for gEDA/gaf (was: [OT] ngspice integration in KiCad)
From: "Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
In-Reply-To: <alpine.DEB.2.11.1608021426490.1398@nimbus>
Date: Tue, 2 Aug 2016 08:50:25 -0700
Message-Id: <0A6C9867-07B5-4CEF-97E8-9B3D358A43FC@sbcglobal.net>
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>
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
X-Mailer: Apple Mail (2.3124)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u72FoW7H008638
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 Aug 2, 2016, at 6: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.

Sure, but its extra work to create all the wrapper objects. And wrapping RIAA with reference counting is a mess.

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

Sure, the wrapper objects from above could provide property change notification. It’s extra work to manage this layer. And when scripts modify the “libcore” POD objects, it might not even be capable of determining a property change occurred.

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

Exactly.

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

I don’t share your concern with either. What is the downside of using Vala? Both would reduce the amount of work needed to implement the GUI. I see significant reward (reduced work) for minimal risk. What can go wrong and what is the chance of it going wrong?

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

Yes, I agree — GUIs require significant work to implement. I disagree with you on the “libcore” responsibilities, because small amounts of additional code at this level can significantly reduce the amount of work needed to implement the GUI level.

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


For example, libgeda has the capability of executing a script to load a component. 

Ed