delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/08/01/23:54:44

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=1470109967; bh=++0JhXNYLQ9qPa9UNN+03njsIz83OTdmGpQjKeCNzlk=; h=Subject:From:In-Reply-To:Date:References:To:From:Subject; b=csGITOrQ41hSHjTJ+/IuagsDHW7fg7usAeB6T5MeoRcPkRV6mFg6DYwLKK9b9nP1aQj3jlGaC6Pkx10PkJ4YR4F3kZX5XquDzKuc9ZJzsFdpUmRnK3ZwA6UQjSnZwR5iIvaRAev6npyepW3EEAW/J+Z8LPmHMlmIvfXi7RVmcLjBbeJpaFy9tpPWD09Cawt5KNrYYvIwEnSeBB0+2EqLu86zBTbSBif8dPOCwPnXQSVJaafuN3nhv3w8bIDhLmzNDDV10inOppYzw8ruiy5AwL3mLUIUSwfGOreZMaI4NEggsFOjWYtQkcSGZXHryKiA7pIwWbNUZJAQhZGauYizVA==
X-Yahoo-Newman-Id: 224492 DOT 24330 DOT bm AT smtp114 DOT sbc DOT mail DOT gq1 DOT yahoo DOT com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 2T4EgQEVM1lNuj6BcHD4y0WbDU..8AM1n0QLCJtQ_seeY2Z
y6ACQVLsjhIyvtiS357nh1SUlZ7ugc9uFcCxH1qdUk1C52PEo8q763v2Zcbj
NKHKs4_PybQJCiKPAiX__DDtX70RrRIkN7sCDwVL_Z_4iu_1u9XViPwwVXZc
1UIMPgg1P8.T7__GW60x3NHnNZeoFqU1ApNo1YhM1v14r8Rt47VEhTYvEPxd
S2A8FkCqnEQ7PkOIMJr2Aggoj_q94plm0e9aW798je7JkMByVpRcFattjVwN
6AAcViyYXUm7AGx98m.DHAAXHTrdo9OQ9owwvqMwTGHYYgbQax8sgJQCjXXf
R9PFrEWKwcEW8yjUwYhyMTUZkSsP9kz2YRosFK2ccmidUGaK3qjU46yLWd9U
h2.aS6KlegDnWvgfmYR10kvnY3fcAUx1RHNpBLyG._cLzt16twEUfNhIaI23
RriGVHgak_UVnpqr1xVwZd3DChHROEUmARiciMIfDNi7lAP5NcfmXIEiojCQ
PsOTxnSTDkZje4inXq4qtFdQ.iHDRn7xtzn6CMfG78529.9InnwQCqv4zCCu
o
X-Yahoo-SMTP: b8jVkbOswBAqZ4BhECp7nxPJUfTGEnEGv_G4qgQeZMeAbA--
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.1607301258260.1409@nimbus>
Date: Mon, 1 Aug 2016 20:52:44 -0700
Message-Id: <939E39F7-B4DA-4B56-A640-C7E6E4ECF955@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>
To: "geda-user AT delorie DOT com" <geda-user AT delorie DOT com>
X-Mailer: Apple Mail (2.3124)
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u723qpwB022075
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 Jul 30, 2016, at 10:22 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
> 
> On Fri, 29 Jul 2016, Edward Hennessy (ehennes AT sbcglobal DOT net) [via geda-user AT delorie DOT com] wrote:
>> What are your plans for the gEDA-gaf codebase? It looks like your are rewriting the core library in other languages. Is your plan to make libgeda obsolete?
> 
> I'd like to have a core library--call it libgeda, call it something else--which is used by the gEDA programs and which can be used in other programs and scripts, as well.  This library should provide an object model and functions for accessing it, for reading and writing files, for rendering objects, and so on.  The idea is that no application or tool working with gEDA files should have to duplicate basic gEDA functionality.
> 
> The current libgeda doesn't live up to that.  While in theory, you could use it in another program for loading gEDA files, in practice, it's so intertwined with gEDA and especially gschem internals that in most cases, it's easier to just duplicate the required behavior.  I'd like to move the parts of libgeda which are interesting to use as a library out into a new library which is used both by libgeda and the tools, merge libgeda back into gschem, and have the new library take the place of libgeda.
> 
> My other concern is the scriptability of gEDA.  While gEDA does have an embedded Guile interpreter and makes some functionality available to it, this approach is somewhat limited; most notably, you can't use the gEDA API from a stand-alone script or from a script running within another application.  I'd prefer having bindings to the core library available in a high-level language and using these both for stand-alone scripts and for code which is run within an application.  This way, the core library could also contain commonly used functionality which is more naturally written in a high-level language, like the netlister.

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?
2. Weak references to basic objects?
3. Property change notifications of some sort? (gobject signals, listener/observer patterns, etc...)

In regards to merging back into gschem, do you see gschem as the schematic editor going forward?

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.
2. Migrate to GTK+3
3. Potentially use a more productive language for gschem and libgschem, like Vala or C#.

However, migrating gschem to GTK+3 seems a heavy lift, especially for only one or two developers -- Probably for the same reasons you see that it is easier crafting a new library than decoupling the existing.

What are your thoughts on a clean restart on the UI?

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.

Ed





- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019