X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sun, 13 Aug 2017 17:30:23 +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: Re: [geda-user] [pcb-rnd] roadmap for data model / drawing primitive cleanup In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-81225215-1502638223=:27212" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-81225215-1502638223=:27212 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 13 Aug 2017, Stephan B=C3=B6ttcher wrote: > gedau AT igor2 DOT repo DOT hu writes: > >> As I wrote earlier, the subcircuit upgrade is not merely replacing >> elements with something that supports "polygons and text on copper" or >> "better paste pattern", but it is a large scale rework of the data >> model. So instead of introducing 10 new special cases for 10 such >> feature requests, we just let users compose arbitrary constructs on >> whatever objects on whatever layers which will automatically solve all >> such feature request. >> >> As a result we will have less number of drawing primitives, but what >> remains will be more generic. Together with subcircuits it will be >> easy to combine them to build up new, non-atomic objects. >> >> We will go from PCB's 11 drawing primitives to only 6 at the end. Less >> is more: you will be able to draw arbitrary smd pad shapes and you >> already can include paste and mask patterns in a subcircuit (that will >> then be the footprint), draw poly on silk and text on copper in your >> footprints, just to name a few possibilities we will get >> automatically. > > How do you envision the mapping of layers from library footprint layers > to the PCB layers? Already solved (was part of release 1.2.4): http://repo.hu/projects/pcb-rnd/devlog/20170629_subc.html "bound layers" section. This is used any time any data leaves a board (into a paste buffer, into=20 a subcircuit, etc.) or any data enters a board (from paste buffer,=20 subcircuit placement, etc.) (I didn't have to use it for elements because elements can't access=20 arbitrary layers, they are hardwired for top and bottom copper and silk=20 via object types and flags.) > > Will there be element attributes to override the default mapping for > individual elements, in the schematic or netlist? Attributes: good idea, we could have that later. Elements: no, they will=20 be removed soon; however binding attributes for subcircuits, potentially=20 settable from the "netlist" import sounds good. Later on I also plan to have a GUI to change the mapping. For now, the=20 automatic mapping works rather well, because of the recipes. When we'll=20 have the GUI you will be able to override the automatic mapping after=20 placement. > Placement styles? What do you mean? > Moving elements from top to bottom side? That's already implemented with subcircuits: the code that is doing the=20 layer recipe swap for side swap is a 8 lines long loop. Since our abstract= =20 layer desription, the "recipe" (called bound layer in the code) says=20 things like "it's on the top silk layer" or "it's on the second copper=20 layer counted from bottom" the side swap is trivial: just need to exchange= =20 "top" & "bottom" in the recipe and call a function to redo the binding=20 (board layer lookup for the new recipe). Regards, Igor2 --0-81225215-1502638223=:27212--