X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Thu, 28 Jan 2016 16:34:14 -0500
Message-Id: <201601282134.u0SLYET7002642@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to:
	<CAC4O8c8prUS=NSm_7BCwkCPntsCRRMCMu9--eXXVBtD0C4pYOg AT mail DOT gmail DOT com>
	(geda-user AT delorie DOT com)
Subject: Re: [geda-user] The nature of gEDA layers
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<CAC4O8c-ZyNnCzCDHXkYYabSD4fG8vf+CKmhMycNJujGMPKzQDQ AT mail DOT gmail DOT com>
	<s6nr3h49hrq DOT fsf AT blaulicht DOT dmz DOT brux>
	<DDB07351-7C94-4B5C-99FA-83750CD4592A AT noqsi DOT com>
	<20160126233332 DOT dec2f06f5c74354a3841989c AT gmail DOT com>
	<s6n1t93h4ub DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160127091746 DOT 1c7a976c2752f913921688ac AT gmail DOT com>
	<s6npowne74w DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160127141334 DOT c738feb9dbeb54a7dec3dff8 AT gmail DOT com>
	<s6n37tjt1tv DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
	<56A8F74B DOT 8080304 AT ecosensory DOT com>
	<CAC4O8c9UKLsh5FAAwUMEtHThKH-w3gUmCU2i9dRW9igkyRt-TQ AT mail DOT gmail DOT com>
	<CAJZxidDmjMtd_fKvR5qZVRa+hwDUbvfaz79oZjkBgDuE1m8RBg AT mail DOT gmail DOT com>
	<56A961BC DOT 3040405 AT ecosensory DOT com>
	<CAJZxidC=nbxAinOtpfGHHqwPXbEMrhfat7jKgA9KBp3EVVg4_Q AT mail DOT gmail DOT com>
	<s6nbn863xlu DOT fsf AT blaulicht DOT dmz DOT brux>
	<56A9E416 DOT 8080500 AT ecosensory DOT com>
	<s6nfuxirm0b DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
	<CAC4O8c9D-F3p8sAm2UumoE+uoMZM1ufSP=mNEPeHHpn8YrcSyg AT mail DOT gmail DOT com>
	<20160128200126 DOT 0fe1bb26d5c28e59d56dfd0e AT gmail DOT com> <CAC4O8c8prUS=NSm_7BCwkCPntsCRRMCMu9--eXXVBtD0C4pYOg AT mail DOT gmail DOT com>
Reply-To: geda-user AT delorie DOT com


> > - Allow more/all things inside Elements, on explicit layers.
> 
> This one in particular is not a small incremental step but a fairly
> drastic change.  A lot of work is likely to be required to fix all the
> points that make assumptions about Elements.  I'm not saying it's a
> bad idea, but it's hard.

Yeah, hard :-)  Internals-wise, the problems are many-fold:

* The GUI needs a way of letting the user specify a BBvia
* The GUI needs to be able to *draw* a BBvia (+1 in 3D mode)
* The GUI needs a way to let the user specify which layer pairs may have BBVias
* The exporters need to know how to export a BBVia (esp drill files)
* DRC needs BBVia-specific rules
* DRC needs to know where BBVias connect to
* Find, likewise
* Report, likewise
* auto-drc needs to know when to let you go "past" a BBVia
* ...which implies a real physical stackup is needed, and enforced
* ...which implies more GUI changes
* will autoroute use BBVias?
* what about the optimizers?
* We need a way of storing BBVias in a file
* ...and storing them internally
* ...and hooking them up to all the object-oriented code throughout
* ...and hooking them up to the rtrees
* ...and teaching rtrees how to find only BBVias that intersect the layers in question
* ...and define "layers in question" accordingly
* etc

So let's call this a "drastic incremental change" - it's doable in the
context of the current code set but it's a lot of work.

But enough talk.  Who's going to do all that work?