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=iVW46XV0TXIT9KUS60uc0WJQiJpZnrnP3AszGoifyOk=; b=W8csrQH9pAUaBu+rjqK87VYGn5KRgwPMktJBgAz9sfoQMf6j3MK8G9b680penYEkmB PYCCA3JK3Kt0U729OSA6F48+Pu8tqAu6f4KNhcPdLZ+MMV52Iu7E5g1kj+sciNrOOr0h 59E5VZXZp5yYZpgCj9mviilZcKYz+AWgf6a2SrAAb+q8l9xP7Icwk41fk66MiKIEpyJq G9A1uQ15qZ4OXe4bRq4rkBsQ2qhcE8mlqlJ7gFvqQ49G3eaAoHX2GfpsX+A2A4I/p4QG m3sI+w/B/TNG0yfu0q7qtq7XGfKklulisXn9F3VzkUcVc+hChykUWvd8Gok+bNqQNjib x16Q== 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=iVW46XV0TXIT9KUS60uc0WJQiJpZnrnP3AszGoifyOk=; b=LFnJLt8xkl81uuX1rr+kryAzGrfRG+PyRj7ce5TZnJPkNuRSmeDVjygyfn0PlC0RCN 5yngA/ICqKKzumZUwcT7gaudMXpUpf/30gMmlyTnDoI6CZ2xlb7grMU66V7DVXRWqlio dlY8Dwklh8Yi9eB/1eghB//ByPbn/sJHnMtU3yBlxfidtG2Ny92KcC1EBmey3nFQo9T2 pLnva2vsnEMbROOfZtIpIVGAilApzz+tLLujAuQDN6toBxm3bDHF4pACdehl7VjOIMH5 P49KhR1e/e9lh859l4PvjfLKfiKep47FU4GQk+ikadO/wsOV9PJcFIaTLqLk/aMHzUKW GR7Q== X-Gm-Message-State: AG10YOQKyV/FqLanasq571Ou1qP6t6m9TxCUzUXm84IPDpOYYykfL/U7JEgAG738FEV2t54yLwT5H2nJv7FquA== MIME-Version: 1.0 X-Received: by 10.28.92.195 with SMTP id q186mr20326195wmb.37.1455655075376; Tue, 16 Feb 2016 12:37:55 -0800 (PST) In-Reply-To: References: <201602122148 DOT u1CLmdjQ014944 AT envy DOT delorie DOT com> <201602122229 DOT u1CMTWui017661 AT envy DOT delorie DOT com> <201602122251 DOT u1CMppdg019442 AT envy DOT delorie DOT com> <201602140215 DOT u1E2FiXp007794 AT envy DOT delorie DOT com> Date: Tue, 16 Feb 2016 11:37:55 -0900 Message-ID: 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]" 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 Tue, Feb 16, 2016 at 3:40 AM, Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] wrote: > I'm pretty sure that the find hotkey will also not follow any connections > where rat lines are not shown. Correct, and this is the correct behavior for find, because it starts from a single point (the hovered point) and traverses from there to find all connected copper. It's the wrong behavior for the Find button however, because the context of the window containing that button indicated that we're finding things associated with the net (or one of it's associated pins/pad), not with any particular point. > > 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. I often don't want to see most of the rats and delete the ones I'm not ready for. It would be annoying for them to get added back in automatically. I don't know if it would be useful as a modal behavior or not. > > 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? Purple (associated with 'found' flag) is what the Find button gives now. I'll look at changing this to start from the selected node. > 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. Mincut is great but probably shouldn't be the default behavior, because it isn't guaranteed to be correct about where the problem is. However.. > 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. ... the existing approach might be worse, I don't know. Britton