Mail Archives: geda-user/2016/02/09/16:04:46
--089e011603f614f967052b5ca8c4
Content-Type: text/plain; charset=UTF-8
Hi...
I'm travelling right now, but you might like to ping a question to Bert. I
reviwed a patch in this area for him, but as I don't have Internet on my pc
on the move, I can't be 100% sure it fixes this particular bug.
As for full polys being the default - I'm uncertain. Harry screwed this up
when he added the polygon algebra... Prior to that polys with no flags were
effectively full, and the introduction of the new code required adding the
full poly flag to recreate the old broken behavior. (As you note, the
connectivity checking code assumes all pieces are connected).
I have a branch which fully implements polygon pour regions that will
operate correctly with connectivity checking for each piece, and even had
experimental support for automatic Island removal (now that did behave in a
moderately surprising way, since no polygon would be left unless you
connected something to it with a thermal, or joined line etc...)
I think implementing full polys with a resurrection of ideas from my old
"pours" branch may be the way to go. I wish we could turn back time and
make the flag "biggest-poly-fragment" so we didn't break very very old
boards...
Harry was not always as careful as we are currently about not breaking
things.
I'd be happy to change the default to full polys once the connectivity
checking works and we have some means for Island removal or small fragment
culling.
There is some code which armed l aimed to remove small fragments, but as
implemented it was broken - hence is disabled. For the incremental polygon
operations to work correctly, we need all the fragments - no matter the
size, so they need excluding with a flag or similar, not just deleting out
of existence.
Peter
On 9 Feb 2016 20:05, "Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:
> On Tue, Feb 9, 2016 at 10:45 AM, Britton Kerin <britton DOT kerin AT gmail DOT com>
> wrote:
> > On Mon, Feb 8, 2016 at 8:39 PM, DJ Delorie <dj AT delorie DOT com> wrote:
> >>
> >> IIRC the option is newer than polygons; the default behavior used to
> >> be the only behavior. If you think it should be changed, come up with
> >> a good case for it and present it in a launchpad bug report.
> >
> > So we have Gabriel also saying they have caused him trouble. The
> > polygon interface is overall weird enough to use that I gave up and
> > didn't bother for years, and that's what I'd like to fix.
> >
> > In thinking it over it is a harder call than I though at first, as
> > tiny invisible conductive slivers could indeed be quite nasty. The
> > proper place to handle this is the connectivity check or DRC though.
> > I'll take a look at how these behave with respect to polygon slivers.
>
> Looks like connectivity tests behave as if full poly is always off:
> they don't notice any poly fragment that would be eliminated if the
> poly wasn't 'full'.
> Given this bug I guess the full poly default can't be changed, but
> sheesh that should really be fixed if we're going to advertise full
> poly as being available at all.
>
> Britton
>
--089e011603f614f967052b5ca8c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Hi...</p>
<p dir=3D"ltr">I'm travelling right now, but you might like to ping a q=
uestion to Bert. I reviwed a patch in this area for him, but as I don't=
have Internet on my pc on the move, I can't be 100% sure it fixes this=
particular bug.</p>
<p dir=3D"ltr">As for full polys being the default - I'm uncertain. Har=
ry screwed this up when he added the polygon algebra... Prior to that polys=
with no flags were effectively full, and the introduction of the new code =
required adding the full poly flag to recreate the old broken behavior.=C2=
=A0 (As you note, the connectivity checking code assumes all pieces are con=
nected).</p>
<p dir=3D"ltr">I have a branch which fully implements polygon pour regions =
that will operate correctly with connectivity checking for each piece, and =
even had experimental support for automatic Island removal (now that did be=
have in a moderately surprising way, since no polygon would be left unless =
you connected something to it with a thermal, or joined line etc...)</p>
<p dir=3D"ltr">I think implementing full polys with a resurrection of ideas=
from my old "pours" branch may be the way to go. I wish we could=
turn back time and make the flag "biggest-poly-fragment" so we d=
idn't break very very old boards...</p>
<p dir=3D"ltr">Harry was not always as careful as we are currently about no=
t breaking things.</p>
<p dir=3D"ltr">I'd be happy to change the default to full polys once th=
e connectivity checking works and we have some means for Island removal or =
small fragment culling.</p>
<p dir=3D"ltr">There is some code which armed l aimed to remove small fragm=
ents, but as implemented it was broken - hence is disabled. For the increme=
ntal polygon operations to work correctly, we need all the fragments - no m=
atter the size, so they need excluding with a flag or similar, not just del=
eting out of existence.</p>
<p dir=3D"ltr">Peter</p>
<div class=3D"gmail_quote">On 9 Feb 2016 20:05, "Britton Kerin (<a hre=
f=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a h=
ref=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]" <<=
a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Feb 9, 201=
6 at 10:45 AM, Britton Kerin <<a href=3D"mailto:britton DOT kerin AT gmail DOT com"=
>britton DOT kerin AT gmail DOT com</a>> wrote:<br>
> On Mon, Feb 8, 2016 at 8:39 PM, DJ Delorie <<a href=3D"mailto:dj AT de=
lorie.com">dj AT delorie DOT com</a>> wrote:<br>
>><br>
>> IIRC the option is newer than polygons; the default behavior used =
to<br>
>> be the only behavior.=C2=A0 If you think it should be changed, com=
e up with<br>
>> a good case for it and present it in a launchpad bug report.<br>
><br>
> So we have Gabriel also saying they have caused him trouble.=C2=A0 The=
<br>
> polygon interface is overall weird enough to use that I gave up and<br=
>
> didn't bother for years, and that's what I'd like to fix.<=
br>
><br>
> In thinking it over it is a harder call than I though at first, as<br>
> tiny invisible conductive slivers could indeed be quite nasty.=C2=A0 T=
he<br>
> proper place to handle this is the connectivity check or DRC though.<b=
r>
> I'll take a look at how these behave with respect to polygon slive=
rs.<br>
<br>
Looks like connectivity tests behave as if full poly is always off:<br>
they don't notice any poly fragment that would be eliminated if the<br>
poly wasn't 'full'.<br>
Given this bug I guess the full poly default can't be changed, but<br>
sheesh that should really be fixed if we're going to advertise full<br>
poly as being available at all.<br>
<br>
Britton<br>
</blockquote></div>
--089e011603f614f967052b5ca8c4--
- Raw text -