Mail Archives: geda-user/2015/10/25/15:58:52
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
- Raw text -