iromero91
commented
7 years ago I propose using DXF LWPOLYLINEs wherever it makes sense, they are basically a list of segments and arcs, arcs are represented as segments with a "bulge" parameter, it may seem a bit confusing at first but it keeps the representation compact. In memory the lwpolyline can be deconstructed as segments and arcs for the purposes of editing.
SchrodingersGat
This is simply for discussion, not ready to be an RFC yet.
One of the current drawbacks of KiCad is the haphazard way that various geometry tools are implemented (or unimplemented). There are inconsistencies between the various views, and the drawing tools that are present are awkward.
Current Deficiencies
Line Ends
Line segments and arc should lock-on to line ends, rather than looking "close enough" but not actually connected.
This could be improved by having more complicated models behind the scenes.
Polygons
In eeschema, polygons can be edited by dragging nodes around (although this requires a weird keypress, and is somewhat non-obvious). You can add nodes fairly simply, and the line segments remain joined as you move node around.
In pcbnew, polygons are simply line segments that get drawn in sequence, but there are no rules actually joining them together. If you subsequently move one line segment, then it is harshly abandoned by its line parents, to survive in the wild, untethered from reality.
This is particularly annoying when you are creating the board outline, which MUST be a closed shape.
Arcs
eeschema and pcbnew both find unique ways of making arc drawing clunky. There should be a way of defining arcs by centre,point,point and also by point,point,point.
Additionally, whenever an arc is created that is not aligned on a simple x,y plane, then it is ridiculously tedious to make this connect with a line endpoint. (This is really more of a UI issue than an issue with the underlying graphic primitives).
Lack of Editing Tools
Many graphical primitives in KiCad are vary hard to edit "after the fact" - and the tools available are not consistent between views.
Geometry Strategies
There are a number of approaches that can be taken with regard to graphical objects:
Separate Simple Primitives
Each graphical "construct" (be it a pad, symbol, board outline, etc) is constructed of unique, simple graphical primitives (such as straight lines, arcs). Each view (schematic, pcb) would need to look at each primitive, and determine if (for e.g.) a set of lines actually form a polygon. This is, generally speaking, the way that KiCad handles graphics - just blit items on top of each other to create (the illusion of) more complex shapes.
Advantages
Disadvantages
Polylines and Arcs
Most shapes can be defined by polylines and arcs. Polylines can be closed and filled to create polygons, arcs can be closed to create circles. There are powerful polygon libs available via boost for performing boolean operations, detecting collisions, etc.
Advantages
Disadvantages
Segment Paths
Another option is to define shapes using path segments that can be curved or straight, which can be used to define lines, arcs, circles, polygons, and complex combinations of any of these.
Advantages
Disadvantages
Qt Features
Qt has reasonably complex graphics tools.
QPainterPath provides drawing of arbitrary paths with straight lines curves
QPolygon provides for drawing polygons (with some simple boolean operations available)
Feedback
What do we think? I think it is important to develop a suite of geometry tools that cover symbols, schematics, footprints, and pcb layout. These should include functions to check for intersection / collision, and intelligently edit shapes on the fly.
In particular, geometric functions are required for defining and testing intersection of copper zones, keepout zones, board outline and cutouts, etc etc