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:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=MiBmIbS4sL80HMSJ4dc+GWq02o3y/dm4GMXci/lDJ/0=;
        b=sD9JDh2Uc/aHOZ5rC16oUZ57ZB8bFKIPKjMh7sPPs0fzI0jtQq8HV+VWZxQfLij3OA
         NeqZPd+9t1IUFCDWpbe2hu8RPdRitbQdDn/N9bWrR4HSVKPSy0JsZQytKMMvFXo7p8AS
         pRyiM7bDBSmRo/dAmoY3lKkB7PPbHuG6TQynVplMVx1JEzWMCsBf8Zj3pUEbb07oE9dR
         o/D3ThyCz1524rNJ+jGRXAKXDfD/DZLCHyTUwKyVsM7q43SdbFaEe4Lp/zklmjbxNcOV
         ZKFfgJ/3HbSORUN8M9JxuOc9f6+UE+GXp855gfbmHNzwcGbWZ73XW6ROdRQdo6cX+wxo
         0EnA==
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=MiBmIbS4sL80HMSJ4dc+GWq02o3y/dm4GMXci/lDJ/0=;
        b=iFHDm+oOmnsDnQO8Gfn1Vs8yjqXFW5CtRTly7o2cMWMNUvViRarTWqvOjIva6FB+dX
         6rvZZyAg3bZCSkTf40pPz1FN10fEh8uARQxOFiYhMm1jF/GXQxEqI7hOtMCUAhGtMVfD
         NjW9rt8Ziwnvb3B0OfIlgjWBFvYIFPVGjd7zDqaQGoRcEc48FB55/FsMIu/2W63WruAN
         L7WuVkSXnO9DQobcVfMPcN4HjWi+a62rKwdHb2mu0StFzGFuH+bxnvldRtJ5BrixGoGt
         NvWml05HsiTSqYFkwzHaEUKg5rhuAX/CR4ELfwm8nd7+zXD6k+hkhPjN9IsrLAGgpEvM
         LmwQ==
X-Gm-Message-State: AG10YOT0V1leAARas0XUbtyL1L3aa9xSgpxpuCObckFxBOc+umGpPw6DqS07T96nB4UyHqVgWsqDkkEpYznTmA==
MIME-Version: 1.0
X-Received: by 10.28.92.195 with SMTP id q186mr14039504wmb.37.1455567653295;
 Mon, 15 Feb 2016 12:20:53 -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:20:53 -0900
Message-ID: <CAC4O8c9E7vVj1mB2FEpyMSpToT=3Cm==savnF7Mq1kuoX8GAhA@mail.gmail.com>
Subject: Re: [geda-user] does Select->Select all found refer exclusively to
 things fouond via netlist?
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
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

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