Mail Archives: geda-user/2015/02/06/14:35:33
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--
- Raw text -