X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Tue, 8 Sep 2015 10:48:13 +0200 (CEST)
From:	Roland Lutz <rlutz AT hedmen DOT org>
To:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] New experimental netlist features
In-Reply-To:	<CAM2RGhRxoVXcv-5jFwMOkb+Ja4=5nAaBYyHQ1BJxfY1ReTRK2Q@mail.gmail.com>
Message-ID:	<alpine.DEB.2.00.1509081004410.2728@lichen>
References:	<alpine DOT DEB DOT 2 DOT 11 DOT 1509031356150 DOT 13201 AT nimbus> <CAM2RGhQD1cbbKZ=OTULMds1TGH1S3oj07W3Z29SJoAyKGm0meQ AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 11 DOT 1509040911430 DOT 1950 AT nimbus> <CAM2RGhRxoVXcv-5jFwMOkb+Ja4=5nAaBYyHQ1BJxfY1ReTRK2Q AT mail DOT gmail DOT com>
User-Agent:	Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:	1.0
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 Fri, 4 Sep 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Fri, Sep 4, 2015 at 3:16 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
>> On Fri, 4 Sep 2015, Evan Foss (evanfoss AT gmail DOT com) [via
>> geda-user AT delorie DOT com] wrote:
>>> Is this built using libgeda or is the whole thing in python?
>>
>> It is built using xorn.geda, which could be described as my take on
>> libgeda3[0].  xorn.geda is mostly written in Python, but the core storage
>> library is written in C for efficiency and interoperability.
>
> Ok I was just wondering how additions to libgeda would effect your
> work. (I really want to add a plugin interface that gives users an
> option other than scheme)

It would not affect it at all, because the netlister (xorn.geda.netlist) 
uses the refactored libgeda subset included with the code (xorn.geda), not 
the original libgeda library.


As for scripting, I'd go with a different approach.  There are basically 
two different problems which scripting is intended to solve:

(1) Allowing programs to access the gEDA functionality.  This includes 
tools which should read or write gEDA files or handle netlists; it also 
includes other GUI applications which interact with the gEDA world.  I 
think the best way to implement this is as a library: these programs 
shouln't be required to start up an actual gEDA binary (as is necessary 
with the GIMP).

(2) Extending the user interface of an existing gEDA application.  This is 
what I call "scripting".  It calls for a much tighter integration with the 
application's codebase which makes supporting more than one scripting 
language impractical.


My work focuses mainly on (1)--making the gEDA functionality available to 
other programs.  This is why I pulled out the parts of libgeda which are 
actually useful outside of the gEDA toolset into a new library 
(xorn.geda).  In order to allow such other programs to work on the file 
currently loaded in the GUI, I created an in-memory "database" which could 
be accessed by more than one codebase at a time (libxornstorage).  This 
somewhat blurs the border between (1) and (2) since stand-alone tools 
could be called as GUI commands, but it's still fundamentally different 
from a script which is executed within (and knows about, and can 
manipulate and extend) the GUI program.

As for scripting, I wouldn't even oppose keeping the current Scheme 
bindings.  Replacing Scheme with a more accessible language would lower 
the barrier to customizing the gschem GUI, but compared to (1), there's 
much less situations in which users would benefit from this.

Roland


>> [0] http://wiki.geda-project.org/libgeda3

- Raw text -