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=googlemail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=bU+8v5FTPCO3NQOiNy5yuJCEIy2hBmPL2pqJ66WqTwM=;
        b=kANpgWSIAC3+LlIeO0gz5i9eQZWQaHimc6/mcIo4k5VPR/CAVMxcSlQc3VOwaNne+v
         BbzC36SeQYYoSDhbBEddYvClpdx3T8fVJwB0JM/lzrplRaYKZR45xgJVDT6mwnPIvyY5
         JBZ362y49nhRSiBq4c1j+f1X4d48sS5Dz1yNS7UYib2pJuHtljZt4x36CqzDY60spDK7
         cRTPv3tZgk05wHmz+n1pneNTTE4waBOO2s4Y2C8D+DQgnWEoWdhyYCP3fPLDAT6Sj0Di
         kdWhnvW8ttnBaVVRZ40CdlT3oKP9BXxP2UD/s8xAKvOBmnszmbFJV5zppS9qTfnICkMh
         MTcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:content-type;
        bh=bU+8v5FTPCO3NQOiNy5yuJCEIy2hBmPL2pqJ66WqTwM=;
        b=UM3XR2P42b/k305ycSYFqp+NZamISnX7F8Quabx1G7L93cxthmknDqN92IBjozRZrA
         PWhb+3VVUdos5sx+z4BhpcvTUye57Ti3r3pnCMMrHBKRFqCsMJvsF86vUdAG4K8wKL9y
         WI3c978FhY1w2HAk7UeH6CVEo8LQkzljCsfj4roEo7OeTTmWbK1vxrkL3StAQwDCMR+N
         L0iN1SshHuxTVIAF4f+RxD5pTCuOhYfyH6HMAzcMHJpS8xs6VEcy+6z5hJ27yj35nEwm
         qiSrrZs7CnmfnQAQsXJiI/9V2fSAtobzG1yAKkHP3uP4d4U7NRqDsC5fLmQU5EesS+Aj
         z0Iw==
X-Gm-Message-State: AG10YOSaSOQwh35xxJHbTKZm1YgHGV5uIHLvK0rkDlwj29THIhxnU9GZZIyrxN9vBtl9Q+cekSG0wVGyEQ7aKg==
MIME-Version: 1.0
X-Received: by 10.182.48.130 with SMTP id l2mr12680193obn.49.1455537522411;
 Mon, 15 Feb 2016 03:58:42 -0800 (PST)
In-Reply-To: <201602140215.u1E2FiXp007794@envy.delorie.com>
References: <CAC4O8c8zXPAOa0owpJKz55Gs+oSKf7fUU9BjGrrKupWzhhCmMw AT mail DOT gmail DOT com>
	<201602122148 DOT u1CLmdjQ014944 AT envy DOT delorie DOT com>
	<CAC4O8c8Gm3JkyoJL1xRq1AvbuvGVNaF+4mRZBt6595tp=xjcPg AT mail DOT gmail DOT com>
	<201602122229 DOT u1CMTWui017661 AT envy DOT delorie DOT com>
	<CAC4O8c8BguZK3=ke+dzOed_GNp-tXPbFE9kP6UQrw2V3tB5W1g AT mail DOT gmail DOT com>
	<201602122251 DOT u1CMppdg019442 AT envy DOT delorie DOT com>
	<CAC4O8c-MiicQhFPJOmGSPgKRHDArOzsPqWeRoOC6fP45oJkZoQ AT mail DOT gmail DOT com>
	<201602140215 DOT u1E2FiXp007794 AT envy DOT delorie DOT com>
Date: Mon, 15 Feb 2016 11:58:42 +0000
Message-ID: <CAJXU7q9uU9GrkhC13NeJOtp7q-Utcd+7nJOCNsqVvN+MhNL-Bw@mail.gmail.com>
Subject: Re: [geda-user] does Select->Select all found refer exclusively to
 things fouond via netlist?
From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA User Mailing List <geda-user AT delorie DOT com>
Content-Type: multipart/alternative; boundary=089e0160b3dcfb1db3052bcdbc0e
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

--089e0160b3dcfb1db3052bcdbc0e
Content-Type: text/plain; charset=UTF-8

I'm not sure where pink comes into the find button in the netlist dialog,
but it may be an unintended behavior...

Some while ago I added a distinction to the "F" behaviour, so it would only
Green colour objects that are physically connected. Objects that are only
connected to the search location by traversing a rat-line get labeled and
coloured differently (pink/purple colour by default).

I did this after missing a connection on a production board, (had a
deliberate short between agnd and dgnd, so the drc / log window wasn't able
to tell me).

Have found it is quite a handy distinction to make, and was more acceptable
to everyone than changing behaviour of "F" to not follow rat lines.

Peter
On 14 Feb 2016 02:17, "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.
>

--089e0160b3dcfb1db3052bcdbc0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I&#39;m not sure where pink comes into the find button in th=
e netlist dialog, but it may be an unintended behavior...</p>
<p dir=3D"ltr">Some while ago I added a distinction to the &quot;F&quot; be=
haviour, so it would only Green colour objects that are physically connecte=
d. Objects that are only connected to the search location by traversing a r=
at-line get labeled and coloured differently (pink/purple colour by default=
).</p>
<p dir=3D"ltr">I did this after missing a connection on a production board,=
 (had a deliberate short between agnd and dgnd, so the drc / log window was=
n&#39;t able to tell me).</p>
<p dir=3D"ltr">Have found it is quite a handy distinction to make, and was =
more acceptable to everyone than changing behaviour of &quot;F&quot; to not=
 follow rat lines.</p>
<p dir=3D"ltr">Peter</p>
<div class=3D"gmail_quote">On 14 Feb 2016 02:17, &quot;DJ Delorie&quot; &lt=
;<a href=3D"mailto:dj AT delorie DOT com">dj AT delorie DOT com</a>&gt; 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"><br>
&gt; That does sound useful.=C2=A0 I guess you do it with first Find button=
 the<br>
&gt; Ctrl-F?=C2=A0 The behavior I get is:<br>
<br>
I &quot;select&quot; one net, then &quot;find&quot; the other net.=C2=A0 Th=
e select code uses<br>
the find flag internally so order matters.<br>
<br>
&gt; Am I correct in thinking that things only appear under Key Bindings if=
<br>
&gt; they don&#39;t have a binding described elsewhere in the menu hierarch=
y?<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&#39;t have a &qu=
ot;home&quot;<br>
elsewhere in the menu gets put in the key bindings list.<br>
<br>
&gt; I&#39;d like the more obscure elements in the menus/hotkeys to be less=
<br>
&gt; forbidding to learn hence tooltip effort.=C2=A0 What do you think of<b=
r>
&gt; putting everything in the hotkeys menu, regardless of whether it<br>
&gt; appears somewhere else as well?=C2=A0 Any other suggestion on how best=
 to<br>
&gt; proceed?<br>
<br>
The menu system isn&#39;t designed for conflicting hotkeys.=C2=A0 I don&#39=
;t know<br>
what would happen if you did that.<br>
</blockquote></div>

--089e0160b3dcfb1db3052bcdbc0e--