X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=aQTtfbWonZa7905WTNW0CC0bBWWvo40/d6oQv3D+9DY=;
	b=WKVksSoO+NXlBa4vDpgzkFgrBGs4yWJGcMMzefOqxOXdNpk0NGDbbEHPzTeBruUqul
	5o30JAgCtjpaHui8ry/iTBv9R9GNsLQIIeHN/XP1d7cSg5Xky2stC2Qt8fa/3VTCRGeA
	fFSePPx+9mqkYH/Dg3e84mK3JBwF6r8HCHdbEXJUTlXyEvSIO8OvqKVco8y231pxziFl
	D7rEHSNAiEgaY/tFiwuirXGWieNzcaggqJcJ5Iy9hv65ac5da9kbBs9IA365BGYELav4
	aaogYhbcB2t+lCFqHoNTw25zTdiO+loJbJaxs2zVP+xdr3yK48HMoC7gjeCXMVUxmShg
	H0lQ==
MIME-Version:	1.0
X-Received:	by 10.152.4.200 with SMTP id m8mr9423002lam.2.1423355021993; Sat,
	07 Feb 2015 16:23:41 -0800 (PST)
In-Reply-To:	<201502072246.t17MktFH026329@envy.delorie.com>
References:	<CAOP4iL2stWVCy3WK0=SNu2zAbs8t6B0uyAgFuOnzG8v_MrYNfw AT mail DOT gmail DOT com>
	<CAGde_xN5gs5r_on=HP2RN7cy6E=2EL9eK3cp+sd9BfBaWNLVew AT mail DOT gmail DOT com>
	<20150204193720 DOT Horde DOT 42xUN-NzhCJRWZne-M5eCQ1 AT webmail DOT in-berlin DOT de>
	<90236728-E79D-47C7-BFB1-34140DB85ACB AT sbcglobal DOT net>
	<CAOFvGD4M48Ap=UQzL_T3yzas2rJrNFfxXRUOkOe8gA8J3bQCHg AT mail DOT gmail DOT com>
	<1423323918 DOT 1592 DOT 10 DOT camel AT cam DOT ac DOT uk>
	<CAOFvGD6rwqf79obnSRQ4gyM0h8_5PQ-C0G2guRp8YU80oOAkig AT mail DOT gmail DOT com>
	<1423329222 DOT 1592 DOT 12 DOT camel AT cam DOT ac DOT uk>
	<54D67B5B DOT 6060205 AT neurotica DOT com>
	<CAM2RGhTsJczAgDN7v1AeO9wRVmJjDCswUNuy=QhzK7eJRVwMuw AT mail DOT gmail DOT com>
	<20150207221252 DOT GA26071 AT recycle DOT lbl DOT gov>
	<201502072246 DOT t17MktFH026329 AT envy DOT delorie DOT com>
Date:	Sat, 7 Feb 2015 19:23:41 -0500
Message-ID:	<CAM2RGhTzA2_JVJAfAg-7wanE-nSah2B9p-bGwrstfK_8DrCmFA@mail.gmail.com>
Subject:	Re: [geda-user] FOSDEM
From:	Evan Foss <evanfoss AT gmail DOT com>
To:	geda-user AT delorie DOT com
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

DJ while those are all really good ideas my impression of the PCB
source is that it would take a lot of work to implement. I want to see
that blue sky doc but in the meanwhile things like copper arcs in
footprints and keep out zones for solder mask would really help out
more. I am pretty sure I am not the best programmer here but to me it
makes the most sense to fix the more basic limitations and then figure
out how to do what you are suggesting.

Understand your frustrations about not getting traction on improving
PCB but I looked at the source for it and gschem a while back.
gschem's source was clear to me, PCB was not. I can not tell if that
is because of my limitations or if it is because PCB is messy. I would
like to help you but I am kind of invested in writing a library to
read bsdl files.

It would be nice to have a draft of what the future PCB file format
would look like building off of what we have now instead of
reinventing the wheel.

I do not mean to be so critical of the people who have put a lot of
hard work into PCB. I still prefer it over say orcad.



On Sat, Feb 7, 2015 at 5:46 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
> I keep thinking about pcb's file (and thus data) format.  I have lots
> of ideas but no traction :-(
>
> Some ideas:
>
> Elements should be able to reference a common footprint or copy it to
> make a private footprint (sketchup does this a LOT).  I.e. all DIP16
> elements should share a common footprint, and editing one should edit
> them all.  Note we have the "inhereted attributes" problem all over
> again, like gschem - the footprint provides a default refdes location
> but nearly every element changes it, but that shouldn't mean needing a
> private footprint definition for each element.
>
> Likewise, footprints should reference a common set of padstacks,
> rather than have N independent but identical padstacks.  There should
> be a way of overriding part of a padstack without having a private
> copy of it?
>
> These "common" definitions should be somewhat independent of the layer
> stackup (i.e. symbolic layer types) and map to the specific layer
> stackup somehow.  This lets developers change the stackup without
> worrying about the footprints, and maybe opens the way to flex cables
> where different regions have different stackups.
>
> PCB should have a concept of a "sublayout" (i.e. four identical input
> channels).  Sublayouts should be movable, rotatable, go on either
> board size, yet if you edit a common one, they all change.  Sublayouts
> should somehow relate to heirarchical schematics, including some rules
> about how to name/rename parts within.
>
> Footprints should be a sublayout :-)
>
> /me starts another blue sky document...



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

- Raw text -