X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Tue, 27 Oct 2015 13:47:50 +0100 (CET)
X-X-Sender:	igor2 AT igor2priv
To:	"Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com]" <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] home/bkerin/geometry_module branch
In-Reply-To:	<CACwWb3B5eTWmAeVVoO_w3Pz-3j6JUAxzpOxTML96E0WzA6wF8w@mail.gmail.com>
Message-ID:	<alpine.DEB.2.00.1510271342490.7137@igor2priv>
References:	<CAC4O8c_0jg9_VbT82H3P7uNi90zg=7O1Bya3ZwPW1MybP-yO9Q AT mail DOT gmail DOT com> <CACwWb3CcWkRz9Wnz+tFKTc+PkP8sZEEJ8kJX=08gM28P4RrE7w AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1510271032140 DOT 7137 AT igor2priv> <CACwWb3Cwwe1kVwH62QOgg1yz7xwOfjW6mdiuikDJ9_iNr+8PAw AT mail DOT gmail DOT com>
	<20151027103752 DOT 17300 DOT qmail AT stuge DOT se> <20151027121151 DOT 84a401be8b0d162eea027ad9 AT gmail DOT com> <CACwWb3B5eTWmAeVVoO_w3Pz-3j6JUAxzpOxTML96E0WzA6wF8w AT mail DOT gmail DOT com>
User-Agent:	Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:	1.0
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 Tue, 27 Oct 2015, Levente (leventelist AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

>
>Okay people... sorry. Calm down.

No worries, I'm totally calm (I use pcb-rnd, and none of these ideas 
affect that fork).

>
>Let us start a technical discussion.
>
>Igor2: I didn't want to reflect your other points.
>
>There is for exaple distance calculation code, polygon handling, so for
>example we could detect polygons that are fully covered by another one. That
>is only one thing.
>But there are others.

I think we should go the other way around. First enumerate what exactly is 
needed to clean up the current code at the parts where things are 
happening nowdays (Britton is in a good position for that, I think). Then 
enumerate what's needed to clean up other parts of the code, like the poly 
dicer or the toporouter. Finally enumerate what kind of plans PCB has for 
the future and what features could potentially help those.

Once there's a list, it makes sense to evaluate libs, see if they provide 
all items on the list and how much extra (useful stuff or bloat) they 
would bring in. If it turns out there's no good deal with existing libs, 
don't be affraid to roll our own.

Picking a lib without these steps seems unreasonable to me.

Regards,

Igor2

- Raw text -