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: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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