X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at av01.lsn.net Subject: Re: [geda-user] The nature of gEDA layers To: geda-user AT delorie DOT com References: <20160126233332 DOT dec2f06f5c74354a3841989c AT gmail DOT com> <20160127091746 DOT 1c7a976c2752f913921688ac AT gmail DOT com> <20160127141334 DOT c738feb9dbeb54a7dec3dff8 AT gmail DOT com> <56A8F74B DOT 8080304 AT ecosensory DOT com> <56A961BC DOT 3040405 AT ecosensory DOT com> <56A9E416 DOT 8080500 AT ecosensory DOT com> <20160128124020 DOT 8f2f33210481f637a696f5d0 AT gmail DOT com> From: John Griessen Message-ID: <56AA3753.6020109@ecosensory.com> Date: Thu, 28 Jan 2016 09:44:19 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed 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 01/28/2016 07:59 AM, Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > The drill-layers are marked as such with a property that is hardwired to > the code that handled connectivity. > > > I would try to keep connectivity and geometry separate if possible. > > Geometry and connectivity needs to be hardwired in the core data > structures. That is the core of what is needed to be efficient while > drawing. > > > Ultimately a layout tool is a connectivity aware drawing package, although some would argue that the connectivity awareness is > optional. You certainly -can- layout a board without net lines, but I think many if not most board designers find them quite useful. The connectivity and geometry are interdependent. If you move a layer up the stack, what is adjacent changes and some of the netlist/ratlines data is now stale. That data can be updated and reconciled by running DRCs usually. Since we almost always use netlist/ratlines data and DRCs, the connectivity doesn't really NEED to be in core data structures -- it can be an attribute associated with a trace or pad's unique ID. One thing needed in core data structures is room for and a mechanism for a unique ID for each atomic board element such as trace, pad, polygon, text... Which brings us to text. Should text be a separate type of atomic board element still? With fonts to swapping out? Could it reduce to a small bitmap and the idea of text and fonts be handled at a higher abstraction level in the code? What about bitmaps? Allow them to be made from square pixels of arbitrary size, or only from other bits of trace atomic board elements?