X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Fri, 6 Feb 2015 20:32:54 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] FOSDEM
In-Reply-To: <CAOuGh8-6ExqHf2pDZ8xHNS05X9DrU5EGQWubNUBsL0jVaYVWdg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1502062024190.8690@nimbus>
References: <1420499386 DOT 3521 DOT 3 DOT camel AT cam DOT ac DOT uk> <CAHBYzfRkn-nJb4JfrDYyaD0WwPrpZvAgi0QdHCusgz185iNoHA AT mail DOT gmail DOT com> <CAGde_xN-iNZUvHh-E47kx1EyoPRt1018wWiDwHhYQ9+od+cJwA AT mail DOT gmail DOT com> <20150203112631 DOT 3507a0c1 AT Parasomnia DOT thuis DOT lan>
 <20150204054256 DOT Horde DOT Pm1JV8RJbICk9SHvIGwZ7A3 AT webmail DOT in-berlin DOT de> <CAOP4iL2stWVCy3WK0=SNu2zAbs8t6B0uyAgFuOnzG8v_MrYNfw AT mail DOT gmail DOT com> <CAGde_xN5gs5r_on=HP2RN7cy6E=2EL9eK3cp+sd9BfBaWNLVew AT mail DOT gmail DOT com> <20150204193720 DOT Horde DOT 42xUN-NzhCJRWZne-M5eCQ1 AT webmail DOT in-berlin DOT de>
 <90236728-E79D-47C7-BFB1-34140DB85ACB AT sbcglobal DOT net> <CAOFvGD4M48Ap=UQzL_T3yzas2rJrNFfxXRUOkOe8gA8J3bQCHg AT mail DOT gmail DOT com> <alpine DOT LNX DOT 2 DOT 02 DOT 1502050141070 DOT 24630 AT localhost DOT localdomain> <54D3B04A DOT 3080308 AT neurotica DOT com> <alpine DOT LNX DOT 2 DOT 02 DOT 1502051225450 DOT 11811 AT localhost DOT localdomain>
 <54D3B7FF DOT 7010401 AT neurotica DOT com> <alpine DOT LNX DOT 2 DOT 02 DOT 1502051337160 DOT 11811 AT localhost DOT localdomain> <54D3CF33 DOT 3000104 AT neurotica DOT com> <CAOuGh8-6ExqHf2pDZ8xHNS05X9DrU5EGQWubNUBsL0jVaYVWdg AT mail DOT gmail DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-876415954-1423251174=:8690"
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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-876415954-1423251174=:8690
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 5 Feb 2015, Bob Paddock wrote:
> In the end this type of thread comes up every couple of years.
> Nothing ever comes of it because no one has the time or resources to
> actually do the work.

Actually, I've been working on this for quite some time!  I implemented a 
set of primitives to allow shared access to gEDA files from GUI and 
standalone programs, including a wrapper module for Python [0, 1].  Also, 
I ported the file reading and writing routines and the attribute mechanism 
to Python to make writing standalone scripts easier.  You can start 
writing Python scripts right now:

> from xorn.geda.read import read
> from xorn.geda.write import write
> from xorn.geda.attrib import search_attached
>
> sch = read('example.sch')
>
> for ob in sch.toplevel_objects():
>     if 'R1' in search_attached(ob, 'refdes'):
>         sch.delete_object(ob)
>
> write(sch, 'example-without-R1.sch')

Currently, only schematic/symbol files are supported, but it shouldn't be 
a problem to add PCB files as well.

The logical next step would be to change libgeda so it uses the Xorn 
primitives.  This would allow multiple parts of the program potentially 
written in different languages to access the file safely at the same time 
(i.e., running scripts on the currently loaded file).


But ultimately, the critical part is not the tools; it is the high-level 
glue layer that holds the tools together.  For example, there is currently 
no easy way for a standalone script to access the netlister 
infrastructure; without this information, many useful operations are much 
more complicated or not possible at all (see the red dot problem).

I'd like to go the step from a well documented schematic and symbol 
interchange format to a well-documented library that provides easy-to-use 
functions for parsing and writing these formats, as well as the 
higher-level functionality required for analyzing and manipulating these 
files in a useful way, such as the netlister.  I believe this is what 
libgeda was originally intended to be.

Duplicating the code would be maintenance-intensive and error-prone. 
Having a scripting API allows in principle to write standalone scripts, 
but it also increases the gap between “core” and “add-on” functionality 
and makes it difficult to access the parts of the machinery that aren't 
exposed via the API.  So this is really a question of porting the core 
components to a common platform.  For an example of how such ported 
libgeda code could look like, see my xorn.geda.attrib module:

https://github.com/rlutz/xorn/blob/master/src/python/geda/attrib.py
http://hedmen.org/xorn/doc/api/html/namespacexorn_1_1geda_1_1attrib.html

John Doty wrote:
> There isn’t a single solution that will satisfy everybody. Many users 
> want an integrated tool, but that is never going to scale well to 
> complex projects with a lot of top level automation.

Maybe not a single “solution”, but definitively a single programming 
environment.  If the GUI doesn't fit your needs, you would be able to use 
the library that implements the functionality used by the GUI and build 
your own features based on this.  As a bonus, you could improve the GUI to 
make your work available to non-programming users.


I will continue working on this, but being on my own, it will take some 
time.  If you are interested in getting this into gEDA, I would much 
appreciate your help.  The logical next step would be to change libgeda so 
it uses the Xorn primitives; also, there is a list of open bugs and tasks 
in the bugtracker [2].  Please get in touch with me so we can coordinate 
the effort.

Roland


[0] http://hedmen.org/xorn/doc/api/html/
[1] https://github.com/rlutz/xorn
[2] http://bugs.hedmen.org/?project=2&order=tasktype&sort=asc

--8323329-876415954-1423251174=:8690--