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: 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]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=047d7b5d95cb6a2fcb0520097c27 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

I pushed to home/bkerin/drc_fixes

They will affect a couple other = things that call CenterDisplay:

find and short rat, bu= t in a good way I think.=C2=A0 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_W= ARP_POINTER of set_crosshair in it.

There's a = warning about this.

While do= ing this I notice a bad behavior or DRC when a violation is formed by for e= xample

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.

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.

--047d7b5d95cb6a2fcb0520097c27--