X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Fri, 11 Sep 2015 12:24:25 -0400
Message-Id: <201509111624.t8BGOPYV000685@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <B94E2C24-8B63-46FC-A551-9E4B14B817C9@noqsi.com> (message from
	John Doty on Fri, 11 Sep 2015 09:51:26 -0600)
Subject: Re: [geda-user] About reinventing the wheel, and how to avoid it
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1509111150410 DOT 2482 AT lichen> <B94E2C24-8B63-46FC-A551-9E4B14B817C9 AT noqsi 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
Precedence: bulk


> Geda-pcb, by contrast, is top-down with restricted goals and
> capabilities.

I like to think of it as "reflecting real-world needs and
goal-oriented features."

> Where geda-gaf describes topology in a general way that has few
> restrictions,

I.e. schematics don't have to worry about copper spacing rules, so
doesn't bother with rules.

> geda-pcb has no general basis in geometry.

Perhaps your theoretical geometry (a layout program is not a 3D cad
program, no matter how much you gripe about it), but it needs to know
a lot more about real-world geometry than gschem does, in ways that
actually benefit real-world layout people.

> Where geda-gaf uses attributes in mostly unrestricted ways,

I.e. gaf doesn't understand attributes at all.

> geda-pcb *enumerates* a restricted subset of possibilities. Adding a
> small subset of possible layer types to this approach has been
> cheered as a great advance here.

We went from two layer types hard-coded to specific layers, to letting
the user specify an arbitrary layer type on arbitrary layers by name.
It is a great advance for us, and we should be proud of the fact that
we're making progress, despite your opposition.

> Sorry, Nicklas, it makes me shudder.

Such drama is inappropriate here, I've asked you to stop many times.
Please stop.

> I expect that a xorn-pcb would be as frustrating. Unlike geda-gaf,
> where the frustrations have been rooted in the implementation, the
> frustrations of geda-pcb are rooted in the design.

Feel free to design your own replacement, but stop complaining about
how we design ours.