delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/02/15/06:58:56

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>
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

--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--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019