X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-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=27/svmpv9S27Amw6/YXEaB4XXES1ehMuYw266AFr82o=;
	b=pBJJwBmvo0u7cRI64dotl9+Ny9xz/hgPChjHAbZIsyQ80CFkKE5r2BogfMr1Z4K6KV
	OeP/cwWNb8kyJrUmDQOEU7ZiI2h+FRbrJnWkV+cvrhA3j5vNoTM0jJyCrzY+ebYr3HNS
	337fWOMt3YYfavedGaEljUAD7nJuolx8cHVXaMOgZIHZkDEWJX5iJKEJj1FCUjFq4tfa
	K8s7lzzja5PKMVs+0c+ks3ym3/wgyqiIZsPRw90+48GrvuX/TMd8RyraNCpgVR5Xqj7L
	dpjCu9l9s5vopOwZlZi8o5FRA31LoxGJTDEPlCogbY627Dc6dqxRLvWvxV+3f2u2ud6w
	5chQ==
MIME-Version:	1.0
X-Received:	by 10.152.27.197 with SMTP id v5mr17186052lag.64.1436485301751;
	Thu, 09 Jul 2015 16:41:41 -0700 (PDT)
In-Reply-To:	<201507092221.t69ML8K2003695@envy.delorie.com>
References:	<1436477539 DOT 1747 DOT 21 DOT camel AT ssalewski DOT de>
	<201507092150 DOT t69Lo53N002627 AT envy DOT delorie DOT com>
	<CAM2RGhStaQk46uUyHEabTpTFriKPoqQCpApWLSaSFZUST-w9TQ AT mail DOT gmail DOT com>
	<201507092221 DOT t69ML8K2003695 AT envy DOT delorie DOT com>
Date:	Thu, 9 Jul 2015 23:41:41 +0000
Message-ID:	<CAM2RGhS-+=KWYOSjELbU3e_dtcsVFYtUaun3jqytKdQORpVNVw@mail.gmail.com>
Subject:	Re: [geda-user] What is the hardest part in a PCB layout program?
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie 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

On Thu, Jul 9, 2015 at 10:21 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
>> That problem seems to be endemic to all EDA not just the pcb part.
>> Perhaps that should be a short term mission. (not trying to push you
>> into it, just trying to find a focusing point)
>
> In pcb, the internal data is a bit hokey.  It would be nice if the
> data could recurse, allowing a footprint to be more than just the few
> things allowed in a footprint, or to handle heirarchical designs more
> cleanly.  There are lots of arbitrary limits in our internal data
> system that could be changed.
>
> Another "short term" project is replacing the ancient object oriented
> design with something easier to maintain.  Huge tables of function
> pointers all over the source is a bad thing these days.

I think that is something that *needs* to be done. It won't be sexy
but it would be good to house in a separate library so that people
working on kicad could handle our files using our code.

OT: I don't really believe in format translation for a lot of stuff it
just leads to a polyglot of re-re-re-translated symbols/footprints and
etc.

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

- Raw text -