Mail Archives: geda-user/2016/02/16/07:41:27
--001a113df2ecb53935052be26f29
Content-Type: text/plain; charset=UTF-8
I'm pretty sure that the find hotkey will also not follow any connections
where rat lines are not shown.
I belive this was at least partly intentional (although the reasoning is
somewhat unclear to me), but is also fairly linked to our implementation of
the connectivity search.
Always up to date rat lines could solve the problem, but I belive some
utilise the feature where you can erase all rats, and re add specific ones
from the netlist dialog box.
The idea to change search start point based on node clicked sounds good to
me. If clicking on the net in general (is this possible?), perhaps invoke
only the purple highlighting?
Shorted connections are the aspect which needs careful consideration
whatever we do... The way things behave in that case really needs to be
clear and predictable.
Igor had a nice min graph cutting based approach for identifying the
probable location of a short in PCB-rnd iirc. That kind of thing might be a
nice pre ratline adding step, that would avoid pcb offering ratlines which
further entangle and short out two (or more?) nets.
Our existing logic for highlighting the bad connection doesn't work well,
and this was the reason Igor started working on the min cut solution.
Anyone who's ever needed to track down a gnd to power short on a complex
board will attest to this being tricky if you don't spot the problem right
away!
Peter
On 15 Feb 2016 20:22, "Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:
> On Sat, Feb 13, 2016 at 5:15 PM, DJ Delorie <dj AT delorie DOT com> wrote:
> >
> >> That does sound useful. I guess you do it with first Find button the
> >> Ctrl-F? The behavior I get is:
> >
> > I "select" one net, then "find" the other net. The select code uses
> > the find flag internally so order matters.
> >
> >> Am I correct in thinking that things only appear under Key Bindings if
> >> they don't have a binding described elsewhere in the menu hierarchy?
> >
> > All key bindings are caused by menu entries, so all key bindings have
> > to be in there somewhere. Any key binding that doesn't have a "home"
> > elsewhere in the menu gets put in the key bindings list.
> >
> >> I'd like the more obscure elements in the menus/hotkeys to be less
> >> forbidding to learn hence tooltip effort. What do you think of
> >> putting everything in the hotkeys menu, regardless of whether it
> >> appears somewhere else as well? Any other suggestion on how best to
> >> proceed?
> >
> > The menu system isn't designed for conflicting hotkeys. I don't know
> > what would happen if you did that.
>
> If I cut a net in half by taking out a wire, then use Find in the
> Netlist dialog, it doesn't show all the pins/pads connected to that
> net. This seems like a bug. If rat lines are included Find follows
> them and gets it right, but shouldn't it get them all anyway, rather
> than picking an arbitrary start point? Perhaps more usefully, if a
> particular node of a net is selected in the nodes pane of the netlist
> dialog, then the search could start from there. This last shouldn't
> be too hard to implement and I'll do it if there aren't objections.
>
> Otherwise at the implementation level it's mostly good as it is. In
> theory it might be nice to use private flags so for example Find (the
> button) didn't nuke the "connected" set (Ctrl-F) and similarly with
> selected and find, but in practice allowing that would open a can of
> worms since there's no visual way to represent things that are in both
> sets. With the order sensitivity at least it's obvious that they
> interact.
>
> Its the interface that's problematic. F stands for find, but actually
> means something different. The Find button could get a name change
> but then it would be inconsistent with the underlying flag name
> (exposed via Ctrl-R and the file format). Changing the F binding is
> obviously a no-no.
> F also handles rat lines by marking them and everything on the other
> side of them as found (but not connected).
>
> I'm just going to document all this, and maybe change the menu entry
> names for F and/or Ctrl-F somehow to make it clear that one clears
> found and connected flags and the other doesn't. To allow for
> cross-refs that don't fall out of sync, hotkeys are going to get their
> own header and the rules that do e.g. gpcb-menu.res.in ->
> gpcb-menu.res change slightly.
>
> Britton
>
--001a113df2ecb53935052be26f29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I'm pretty sure that the find hotkey will also not follo=
w any connections where rat lines are not shown.</p>
<p dir=3D"ltr">I belive this was at least partly intentional (although the =
reasoning is somewhat unclear to me), but is also fairly linked to our impl=
ementation of the connectivity search.</p>
<p dir=3D"ltr">Always up to date rat lines could solve the problem, but I b=
elive some utilise the feature where you can erase all rats, and re add spe=
cific ones from the netlist dialog box.</p>
<p dir=3D"ltr">The idea to change search start point based on node clicked =
sounds good to me. If clicking on the net in general (is this possible?), p=
erhaps invoke only the purple highlighting?</p>
<p dir=3D"ltr">Shorted connections are the aspect which needs careful consi=
deration whatever we do... The way things behave in that case really needs =
to be clear and predictable.</p>
<p dir=3D"ltr">Igor had a nice min graph cutting based approach for identif=
ying the probable location of a short in PCB-rnd iirc. That kind of thing m=
ight be a nice pre ratline adding step, that would avoid pcb offering ratli=
nes which further entangle and short out two (or more?) nets.</p>
<p dir=3D"ltr">Our existing logic for highlighting the bad connection doesn=
't work well, and this was the reason Igor started working on the min c=
ut solution.</p>
<p dir=3D"ltr">Anyone who's ever needed to track down a gnd to power sh=
ort on a complex board will attest to this being tricky if you don't sp=
ot the problem right away!<br></p>
<p dir=3D"ltr">Peter<br><br></p>
<div class=3D"gmail_quote">On 15 Feb 2016 20:22, "Britton Kerin (<a hr=
ef=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a =
href=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>> wrot=
e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Feb 13, 2=
016 at 5:15 PM, DJ Delorie <<a href=3D"mailto:dj AT delorie DOT com">dj AT delorie=
.com</a>> wrote:<br>
><br>
>> That does sound useful.=C2=A0 I guess you do it with first Find bu=
tton the<br>
>> Ctrl-F?=C2=A0 The behavior I get is:<br>
><br>
> I "select" one net, then "find" the other net.=C2=
=A0 The select code uses<br>
> the find flag internally so order matters.<br>
><br>
>> Am I correct in thinking that things only appear under Key Binding=
s if<br>
>> they don't have a binding described elsewhere in the menu hier=
archy?<br>
><br>
> All key bindings are caused by menu entries, so all key bindings have<=
br>
> to be in there somewhere.=C2=A0 Any key binding that doesn't have =
a "home"<br>
> elsewhere in the menu gets put in the key bindings list.<br>
><br>
>> I'd like the more obscure elements in the menus/hotkeys to be =
less<br>
>> forbidding to learn hence tooltip effort.=C2=A0 What do you think =
of<br>
>> putting everything in the hotkeys menu, regardless of whether it<b=
r>
>> appears somewhere else as well?=C2=A0 Any other suggestion on how =
best to<br>
>> proceed?<br>
><br>
> The menu system isn't designed for conflicting hotkeys.=C2=A0 I do=
n't know<br>
> what would happen if you did that.<br>
<br>
If I cut a net in half by taking out a wire, then use Find in the<br>
Netlist dialog, it doesn't show all the pins/pads connected to that<br>
net.=C2=A0 This seems like a bug.=C2=A0 If rat lines are included Find foll=
ows<br>
them and gets it right, but shouldn't it get them all anyway, rather<br=
>
than picking an arbitrary start point?=C2=A0 Perhaps more usefully, if a<br=
>
particular node of a net is selected in the nodes pane of the netlist<br>
dialog, then the search could start from there.=C2=A0 This last shouldn'=
;t<br>
be too hard to implement and I'll do it if there aren't objections.=
<br>
<br>
Otherwise at the implementation level it's mostly good as it is.=C2=A0 =
In<br>
theory it might be nice to use private flags so for example Find (the<br>
button) didn't nuke the "connected" set (Ctrl-F) and similarl=
y with<br>
selected and find, but in practice allowing that would open a can of<br>
worms since there's no visual way to represent things that are in both<=
br>
sets.=C2=A0 With the order sensitivity at least it's obvious that they<=
br>
interact.<br>
<br>
Its the interface that's problematic.=C2=A0 F stands for find, but actu=
ally<br>
means something different.=C2=A0 The Find button could get a name change<br=
>
but then it would be inconsistent with the underlying flag name<br>
(exposed via Ctrl-R and the file format).=C2=A0 Changing the F binding is<b=
r>
obviously a no-no.<br>
F also handles rat lines by marking them and everything on the other<br>
side of them as found (but not connected).<br>
<br>
I'm just going to document all this, and maybe change the menu entry<br=
>
names for F and/or Ctrl-F somehow to make it clear that one clears<br>
found and connected flags and the other doesn't.=C2=A0 To allow for<br>
cross-refs that don't fall out of sync, hotkeys are going to get their<=
br>
own header and the rules that do e.g. <a href=3D"http://gpcb-menu.res.in" r=
el=3D"noreferrer" target=3D"_blank">gpcb-menu.res.in</a> -><br>
gpcb-menu.res change slightly.<br>
<br>
Britton<br>
</blockquote></div>
--001a113df2ecb53935052be26f29--
- Raw text -