X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sun, 25 Oct 2015 21:00:31 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] [pcb-rnd] new feature: cycle drag In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Sun, 25 Oct 2015, Kai-Martin Knaak wrote: > gedau AT igor2 DOT repo DOT hu wrote: > >> yesterday afternoon, after a brainstorming session with Bert, I've >> implemented a minor feature that fixes a long standing annoyance >> around moving objects in PCB. It allows the user to select which one >> object to move in case there are multiple objects could be moved >> from the same point. > > A better way to deal with ambiguous selection would indeed be a > significant improvement in usability. > > Some questions: > > * How does the user get to know that there is an ambiguity in the > first place? Changed graphics of the mouse pointer? A remark in the > status line? Good idea. Currently it doesn't do any of that, you just start dragging and when you realize you are dragging an object you didn't want to, press x and it switches to dragging a different object. You cycle until you find the object you wanted to drag (the other objects you cycled through are all put back). > > * How does the user know, which choice is the current one? There's a traditional outline highlight feature while dragging or drawing, it shows what would happen. At the moment you click to drag, it already outlines one object; when you press 'x', it outlines another. I think it's visible on the video, despite of the compression. > * What happens if the user ignores the possibility to cycle and just > drags? The very same thing as before: drag one object "randomly". The "random" algo didn't change either, so an user not looking for this feature wouldn't experience any change. > * What is the geometric scope of the action? That is, how close do > objects have to be to be included in the cycle? The same distance as for the drag in the first place. I mean when you click somwhere, the code has a range for deciding what you wanted to click on - I use the same value for listing all other candidates. I also stick to non-locked, visible objects. > * The HTML page mentions, the action does not work if rubberband move > is enabled. What is the actual reason? Could this be overcome? Reason: didn't yet have the time to look into it. It should be fixed. I don't see how exactly it interfers with the rubber band mode. It shouldn't, because it's just dragging one object, as without cycling. Rubber band should happen after the mouse button release. Maybe I set up some of the 3 magic (void *) pointers the wrong way when cycling to the next object; maybe some precalculated coordinates depend on the original object to be moved and that confuses rubber band code later. I will look into it later. Regards, Igor2