Mail Archives: geda-user/2016/01/04/11:58:50
On Sat, 2 Jan 2016, karl AT aspodata DOT se wrote:
> Roland Lutz:
>> On Sat, 2 Jan 2016, karl AT aspodata DOT se wrote:
>>> and move xorn to a more finished state, as far as scripting is
>>> conserned ?
>>
>> Yes, that's the idea.
>
> Ok, I'm in. But I have to fix my dev box first, a week or so.
:)
As far as gEDA/gaf is concerned, the logical next step would be to have
gschem use the Xorn data structures and storage library. However, this
would mean that either the libgeda dependencies would have to be untangled
first, or libgedacairo and the other programs using libgeda (gaf, gattrib,
gnetlist, gsymcheck, utils/gschlas, contrib/sarlacc_schem) would have to
be ported to Xorn in the same process which would make things
significantly more complicated.
My approach so far has been to port the other programs to Xorn first.
I've already done this with the most complex program, gnetlist, and
started porting libgedacairo and gattrib. However, there are some
unexpeced problems:
* having a Guile API seems to be important for some users, but Guile
doesn't seem to provide Python bindings
* libgedacairo implements overbar text in a way that isn't compatible with
the Python bindings for Pango
* gattrib uses a GTK spreadsheet widget which isn't supported any more,
and there doesn't seem to be a functionally equivalent alternative
Therefore, it might be necessary to split the libgeda code and keep an
unmodified version around for some time. This way, gschem and libgeda
could be refactored together without having to worry about breaking the
other programs.
- Raw text -