X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Injected-Via-Gmane: http://gmane.org/
To: geda-user AT delorie DOT com
From: Peter TB Brett <peter AT peter-b DOT co DOT uk>
Subject: Re: [geda-user] libgeda Python bindings?
Date: Fri, 16 Aug 2013 19:26:18 +0100
Lines: 74
Message-ID: <87a9khjxv9.fsf@harrington.peter-b.co.uk>
References: <51DCEE37 DOT 9040303 AT sonic DOT net>
	<alpine DOT DEB DOT 2 DOT 10 DOT 1307101421060 DOT 5186 AT home DOT local>
	<51DD9F48 DOT 90908 AT sonic DOT net>
	<alpine DOT DEB DOT 2 DOT 10 DOT 1307102353160 DOT 4392 AT home DOT local>
	<51DED0D4 DOT 2020705 AT sonic DOT net>
	<alpine DOT DEB DOT 2 DOT 10 DOT 1308071457340 DOT 5268 AT home DOT local>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
X-Complaints-To: usenet AT ger DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: cpc4-oxfd23-2-0-cust628.4-3.cable.virginmedia.com
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
Cancel-Lock: sha1:B8J+zEicNwh59mfkxJGCZ/IPz2Q=
Reply-To: geda-user AT delorie DOT com

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Roland Lutz <rlutz AT hedmen DOT org> writes:

> A short update for the Python bindings/translation:
>
> I tried both ways (creating a Python wrapper using swig, and
> translating the relevant parts of libgeda to Python) and found it to
> be much more difficult than expected.  The main problems I experienced
> are:
>
> 1. The gschem GUI code is not cleanly separated from the libgeda code;
> in fact, about half of libgeda is dealing with GUI issues.

I would say that that is quite an exaggeration. However, yes, there is
still too much GUI support code in libgeda. pcjc2 and I have only being
trying to cut it out since 2006...

> 2. There is some semi-working (e.g., no arcs) support for SVG paths
> which has been implemented by copying and adapting parts of rsvg.

That's not exactly an accurate description.  pcjc2 wanted to add support
for paths.  SVG has a convenient and compact path formatting syntax, so
it seemed like a good idea to adopt that rather than reinventing the
wheel.  In a similar spirit of re-use, it made sense to adapt some
compatibly licensed code from librsvg.  However, there was no intent at
any point to fully support arbitrary SVG paths.

> 3. The bounding box of text objects can only be determined using the
> Cairo renderer.

Or any other renderer that registers the appropriate callback
function. (I.e. the bounding box of text objects depends on how the
renderer decides to draw the text).  We (pcjc2 and I) thought long and
hard about this and there didn't seem to be any better way of doing this
that would be able to ensure that the bounding box of a text object was
actually the bounding box of the text, apart from by putting a full font
renderer into libgeda.

> (This is the main reason why libgeda has to know about TOPLEVEL
> contexts.)

This is a highly inaccurate statement.

> 4. .sch/.sym files can only be parsed correctly after executing the
> configuration files.  (I consider this a major anti-feature.)

Me too.  Unfortunately there are some issues that make it inevitable
that loading depends on *some* configuration (for example, search
paths).  I have an ongoing, stalled project (see Launchpad blueprints)
for converting all config to being parsed rather than executed, but it
has some fairly gnarly dependencies obstructing it.  If someone wanted
to picke it up and run with it I'd be happy to provide advice.

Peter

=2D-=20
Peter Brett <peter AT peter-b DOT co DOT uk>
Remote Sensing Research Group
Surrey Space Centre

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iEYEARECAAYFAlIObsoACgkQZ7Gbq7g7vpr+5QCdH+bZANIrnyo2ns6Z7eWy4u5U
vPsAoIkXHFrUo14LTSw11NSnYjkCr3NS
=WCOH
-----END PGP SIGNATURE-----
--=-=-=--