Mail Archives: geda-user/2015/10/03/00:04:17
--047d7b5d95cb158e6205212b5d35
Content-Type: text/plain; charset=UTF-8
On Fri, Oct 2, 2015 at 6:41 PM, Kai-Martin Knaak <kmk AT familieknaak DOT de>
wrote:
Britton Kerin wrote: > * The magic that detects both these condition is
AddAllRats(). It > sets a variety of global state > for various problems
of interest like the above. So it could be > called on DRC refresh and
used > to generate DRC reports for these problems. I'd very much prefer
this approach. A warning issued on DRC no matter
what does not work for me. In the long run, I will get so used to it
Getting used to it is problem for sure. But at the moment, you already
know DRC doesn't tell you everything, so the situation is no worse for you,
and its a lot better for the new user who should read the warning at least
the first time it pops up. It's a completely revertable one-liner versus
maybe a day and considerably more complexity to do it the other way. I
think there are more important things than getting this perfect right now.
that I routinely ignore it. Everything the DRC complains about should
refer to actual problems as opposed to potential problems.
Ideally yes but I think this is not a reason to not do the quick fix, since
it's still quite a lot better than the current confusing and potentially
expensive behavior. The current behavior is potentially worst for a so far
largely unconsidered class of user that I think we should focus on much
more heavily: new users modifying an existing design.
> The problem is it's destructive: it resets the rats > so if the user
is trying to work on a subset of the board while > sometimes doing DRC
refresh it's going to be annoying. You mean a use case where the user
manually deletes long range rats to
get a better feel for the local situation? IMHO, a delete is already a
Sort of, but can can also "Optimize selected rats" (very confusing term for
noobs btw), which is a lot easier and therefore a more likely use case. I
generally do this during early routing because its much less of a mess to
identify the rats you want.
crutch in itself. The GUI should instead offer an easy way to mark
specific rats as "ignored". Ignored rats would not be considered on
"update rats" connection check. Just like the check already ignores
nets marked with a star in the net list.
Hmm I didn't know about this
This should of course be complemented by the ability to un-ignore.
Ideally it would allow for partial un-ignore. But a simple un-ignore-
all would be sufficient.
I agree that something like this could be convenient. I have boards where
certain rats are never routed because external straps and such are used and
it somewhat bugs me. But I think not enough that I want to add this many
features. I don't know if other users have more need or not. Such things
should probably get a schematic symbol anyway...
I have a feeling, that this kind of ignore might not be easy. Current
connection check probably does not care for rats but looks at the
items in the net list.
That said, how about a checkbox in the DRC dialog to activate
automatic connection check as part of the DRC run?
The problems with this are:
* unless you do a lot of work to do the above stuff, the results of the
checks still won't make it into the DRC window, you'll just get messages
and maybe a little bit of orange on the main display. AddAllRats sets some
global warning flags so I guess you could then create a DRC only if it sets
those
* it's not obvious how to do it for non-gtk. An pop-up dialog to choose
this each time would be really annoying
* it's still a lot more trouble than the one-liner even ignoring these
issues
--047d7b5d95cb158e6205212b5d35
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>On Fri, Oct 2, 2015 at 6:41 PM, Kai-Martin Knaak <<a href=3D"mailto:=
kmk AT familieknaak DOT de">kmk AT familieknaak DOT de</a>> wrote:<br><br>=C2=A0=C2=A0=
=C2=A0 Britton Kerin wrote: > * The magic that detects both these condit=
ion is AddAllRats().=C2=A0 It > sets a variety of global state > for =
various problems of interest like the above.=C2=A0 So it could be > call=
ed on DRC refresh and used > to generate DRC reports for these problems.=
I'd very much prefer this approach. A warning issued on DRC no matter<=
br>=C2=A0=C2=A0=C2=A0 what does not work for me. In the long run, I will ge=
t so used to it<br><br>Getting used to it is problem for sure.=C2=A0 But at=
the moment, you already know DRC doesn't tell you everything, so the s=
ituation is no worse for you, and its a lot better for the new user who sho=
uld read the warning at least the first time it pops up.=C2=A0 It's a c=
ompletely revertable one-liner versus maybe a day and considerably more com=
plexity to do it the other way.=C2=A0 I think there are more important thin=
gs than getting this perfect right now.<br>=C2=A0<br>=C2=A0=C2=A0=C2=A0 tha=
t I routinely ignore it. Everything the DRC complains about should<br>=C2=
=A0=C2=A0=C2=A0 refer to actual problems as opposed to potential problems.<=
br><br>Ideally yes but I think this is not a reason to not do the quick fix=
, since it's still quite a lot better than the current confusing and po=
tentially expensive behavior.=C2=A0 The current behavior is potentially wor=
st for a so far largely unconsidered class of user that I think we should f=
ocus on much more heavily: new users modifying an existing design.<br><br>=
=C2=A0=C2=A0=C2=A0 > The problem is it's destructive: it resets the =
rats > so if the user is trying to work on a subset of the board while &=
gt; sometimes doing DRC refresh it's going to be annoying. You mean a u=
se case where the user manually deletes long range rats to<br>=C2=A0=C2=A0=
=C2=A0 get a better feel for the local situation? IMHO, a delete is already=
a<br><br>Sort of, but can can also "Optimize selected rats" (ver=
y confusing term for noobs btw), which is a lot easier and therefore a more=
likely use case.=C2=A0 I generally do this during early routing because it=
s much less of a mess to identify the rats you want.<br>=C2=A0<br><br>=C2=
=A0=C2=A0=C2=A0 crutch in itself. The GUI should instead offer an easy way =
to mark<br>=C2=A0=C2=A0=C2=A0 specific rats as "ignored". Ignored=
rats would not be considered on<br>=C2=A0=C2=A0=C2=A0 "update rats&qu=
ot; connection check. Just like the check already ignores<br>=C2=A0=C2=A0=
=C2=A0 nets marked with a star in the net list.<br><br>Hmm I didn't kno=
w about this<br>=C2=A0<br>=C2=A0=C2=A0=C2=A0 This should of course be compl=
emented by the ability to un-ignore.<br>=C2=A0=C2=A0=C2=A0 Ideally it would=
allow for partial un-ignore. But a simple un-ignore-<br>=C2=A0=C2=A0=C2=A0=
all would be sufficient.<br><br>I agree that something like this could be =
convenient.=C2=A0 I have boards where certain rats are never routed because=
external straps and such are used and it somewhat bugs me.=C2=A0 But I thi=
nk not enough that I want to add this many features.=C2=A0 I don't know=
if other users have more need or not.=C2=A0 Such things should probably ge=
t a schematic symbol anyway...<br><br>=C2=A0=C2=A0=C2=A0 I have a feeling, =
that this kind of ignore might not be easy. Current<br>=C2=A0=C2=A0=C2=A0 c=
onnection check probably does not care for rats but looks at the<br>=C2=A0=
=C2=A0=C2=A0 items in the net list.<br><br>=C2=A0=C2=A0=C2=A0 That said, ho=
w about a checkbox in the DRC dialog to activate<br>=C2=A0=C2=A0=C2=A0 auto=
matic connection check as part of the DRC run?<br><br><br>The problems with=
this are:<br><br>* unless you do a lot of work to do the above stuff, the =
results of the checks still won't make it into the DRC window, you'=
ll just get messages and maybe a little bit of orange on the main display.=
=C2=A0 AddAllRats sets some global warning flags so I guess you could then =
create a DRC only if it sets those<br><br>* it's not obvious how to do =
it for non-gtk.=C2=A0 An pop-up dialog to choose this each time would be re=
ally annoying<br><br>* it's still a lot more trouble than the one-liner=
even ignoring these issues<br><br>
--047d7b5d95cb158e6205212b5d35--
- Raw text -