X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Sun, 16 Oct 2016 10:32:17 +0200 (CEST)
X-X-Sender:	igor2 AT igor2priv
To:	geda-user AT delorie DOT com
X-Debug:	to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From:	gedau AT igor2 DOT repo DOT hu
Subject:	[geda-user] [pcb-rnd] 6 more import/export plugins + call for testers
Message-ID:	<alpine.DEB.2.00.1610161008090.7286@igor2priv>
User-Agent:	Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:	1.0
Reply-To:	geda-user AT delorie DOT com

Hi all,

I have plans to clean up the core code a bit, including the internal data 
representation. (This would be the second step to solve those old problems 
like "copper text/arc/anything in element", "b/b vias", "polyon pads", 
"pad stack", "better representation of physical layers", etc. But this 
mail is not about those.)

Once I start that clean up, it'll be harder to port mainline HIDs to 
pcb-rnd, so I decided to port all the plugins/exporters available now - 
10 feature plugins last week, and 6 import/export modules this week:
  - dsn export (specctra, for autorouting)
  - dsn import (used to be part of the dsn export HID)
  - openscad export (3d, original name: scad HID)
  - dxf export (3d/mech cad)
  - breadboard export
  - ipcd356 export (automated electrical testing)

If you need any of these features then I need your help: please read on.

The full list with current states:

http://repo.hu/projects/pcb-rnd/features/oldplugins.html

They all compile now so they are no longer blocking the future cleanings - 
that was the initial goal of porting them. However, I am not sure they are 
working properly or whether any user would use these at all. This means 
all these new plugins are in a frozen state until user demand appears.

Dear gEDA user, if you are interested in using any if these exporters 
please contact me, because we need to do some testing and potentially some 
bugfixing and improvements. If there's actual user demand (and resources 
to test) behind any of these exporters, I believe I could get them 
properly working in a matter of 1..2 weeks.

If there's no user demand, I'd just keep them in their current state: 
compilable but who-knows-if-really-works, constantly forward porting 
during the clean ups.

Regards,

Igor2

- Raw text -