X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Message-ID: <1402447930.3185.76.camel@pcjc2lap> Subject: Re: [geda-user] Prerequisites for a STEP exporter - call for assistance. From: Peter Clifton To: geda-user AT delorie DOT com Date: Wed, 11 Jun 2014 01:52:10 +0100 In-Reply-To: <539771CF.5000506@xs4all.nl> References: <1402355532 DOT 14291 DOT 63 DOT camel AT pcjc2lap> <539771CF DOT 5000506 AT xs4all DOT nl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 2014-06-10 at 22:59 +0200, Bert Timmerman wrote: > > I might find some spare cycles in the near future. > > Depending on what parts to do and when needed (road map please). I'll try and hash something out when I get a few cycles myself! One item will be working out a design for the UI of an editor for all these new exciting poly-curve-loop entities we will start adding to represent board outlines, footprint courtyards, complex pad shapes etc... I'm thinking we could eventually end up with something like a basic dumbed down of an MCAD sketcher, supporting lines, arcs, and the concept of "snapping". Bonus points for making it a little parametric, e.g. allowing definition of driving dimensions. In the first instance - just a grid based editor with snapping would be enough, assuming we can write a simple algorithm to check for the required simple closed path, with "near enough to snap" end-points. Adding arc segments to polygons with our current editing scheme will be hard. I think we need to "activate" editing, and explicitly show the lines which make the poly(gon|curve), along with handles - and the ability to delete and re-create individual segments of the outline sketch as independent entities. When leaving editing, we would then need to validate the geometry (and accept it, or prompt the user to discard or continue editing if there is a problem). > It might be a good idea to start a topic branch "devel" for this > development on the upstream repo. Possibly. The code I have is clean enough (ish), and self-contained enough to be separable from the PCB+GL stuff it is currently sitting on top of. It just wants a little tidy up, and a few WIP patches squashing together. > Maybe we need a "wall" for scribbles on the Launchpad bug report system > to stay in sync with other developers and contributors. > > Maybe we need to get organised at IRC #geda on regular time slices (EU > and/or US time zones ?), and have code sprints. > > Or remain with "business as usual" ;-( and have 1 accidental commit > per month (me thinks not funny !). Hey.. most of my recent commits HAVE been deliberate, even if seemingly random in nature ;) > I'm not very strong with C coding skills or "managing" software > projects, maybe documenting stuff and bug hunting. > > I do know that development on pcb is on the brink of stalling, so FWIW, > I will put my shoulders under this initiative. > > On to pcb-4.0 !! Meh - 2.0. I'm not inclined to recognise a fork which didn't change the name. (Or perhaps WE should change our name!). Peter -- Peter Clifton Clifton Electronics