delorie.com/archives/browse.cgi | search |
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:date:message-id:subject:from:to:content-type; | |
bh=1yGgnqkdf4FoazdCsv2Y1DXd6E6koDUWlHhPURMp2qo=; | |
b=Yo3tmMK2OX5AfBDTTtJcJAKClJoZtOPJ27piX3lRpX0ZX4+ekYZlxzr5BCCq7MgQft | |
n7OV/u9JOZBfn158NtnYwSV4wY3YraBLSUeoA9bZCCpXRXCgyPOy5pERmivdNk05Axp6 | |
EyUBHaj3fNKUTM+NV53KC3knVmFee/vRE/sIkBdg+fXj1/Gf6eZwuEHtIaTn5sO6V1Uu | |
o6oLAeWEZHBHyDXnQl7IR2mNToIXzoaKLwfyLATa18+zsLa3COz+Rs4jtTf4mgUBsLf1 | |
aae/NQSjipZlWHzLkczjU6rnKyvQyDAR07mnIwY0F0nlKDrjUlAQY+0zaVpsj5b7C8Eg | |
tN9g== | |
MIME-Version: | 1.0 |
X-Received: | by 10.194.21.199 with SMTP id x7mr9404494wje.63.1442599997679; |
Fri, 18 Sep 2015 11:13:17 -0700 (PDT) | |
Date: | Fri, 18 Sep 2015 10:13:17 -0800 |
Message-ID: | <CAC4O8c8s4Squ8H8C-fBtUAy1-Nii0W7eEW4KwGiePRsW-5LvpA@mail.gmail.com> |
Subject: | [geda-user] gtk DRC fixes pushed, next steps for DRC |
From: | "Britton Kerin (britton DOT kerin 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 |
--047d7b5d95cb6a2fcb0520097c27 Content-Type: text/plain; charset=UTF-8 I pushed to home/bkerin/drc_fixes They will affect a couple other things that call CenterDisplay: find and short rat, but in a good way I think. CenterDisplay wasn't actually centering the display, now it does. Lesstif is still broken but no more than it was, the fix would be to implement HID_SC_CENTER_IN_VIEWPORT_AND_WARP_POINTER of set_crosshair in it. There's a warning about this. While doing this I notice a bad behavior or DRC when a violation is formed by for example a long trace and a too-near short trace. DRC produces two violations, one for each trace. This is conservative and I wouldn't try to change it. The problem is the violation location for the long trace is reported as the center of the long trace, and this violation may be reported *before* the violation for the short trace. When you go there the actually problem is way far away and therefore mysterious. I think the fix for this is to present DRC violations (within a violation type at least, I dunno exactly yet) in order of increasing size of the objects involved. This way the user can work top-to-bottom fixing errors and secondary failures (e.g. the symmetric violation for the long trace) will never have to be seen. If there are no objections I'll do this next. --047d7b5d95cb6a2fcb0520097c27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div style=3D"">I pushed to home/bkerin/drc_fixes</div= ><div style=3D""><br></div><div style=3D"">They will affect a couple other = things that call CenterDisplay:</div><div style=3D"">find and short rat, bu= t in a good way I think.=C2=A0 CenterDisplay wasn't actually</div><div = style=3D"">centering the display, now it does.</div><div style=3D""><br></d= iv><div style=3D"">Lesstif is still broken but no more than it was, the fix= would be to implement</div><div style=3D"">HID_SC_CENTER_IN_VIEWPORT_AND_W= ARP_POINTER of set_crosshair in it.<br></div><div style=3D"">There's a = warning about this.</div><div style=3D""><br></div><div style=3D"">While do= ing this I notice a bad behavior or DRC when a violation is formed by for e= xample</div><div style=3D"">a long trace and a too-near short trace.=C2=A0 = DRC produces two violations, one for each trace.=C2=A0 This is conservative= and I wouldn't try to change it.=C2=A0 The problem is the violation lo= cation for the long trace is reported as the center of the long trace, and = this violation may be reported *before* the violation for the short trace.= =C2=A0 When you go there the actually problem is way far away and therefore= mysterious.</div><div style=3D"">I think the fix for this is to present DR= C violations (within a violation type at least, I dunno exactly yet) in ord= er of increasing size of the objects involved.=C2=A0 This way the user can = work top-to-bottom fixing errors and secondary failures (e.g. the symmetric= violation for the long trace) will never have to be seen.=C2=A0 If there a= re no objections I'll do this next.</div><div style=3D""><br></div></di= v> --047d7b5d95cb6a2fcb0520097c27--
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |