Shift+Move needs proper pixel spacing between objects

[P@Anand]

This one is more kind of a cleanup to the algorithm. 

In the Front Panel to move a set of objects pressing the arrow button or Mouse drag helps. But one more option to move the objects faster according the grid size is by Holding the shift key and using the arrow key to move. When observed the pixel distance between the object changes in the last method, which is not correct. So it would be great if this is fixed in the feature versions.

To understand the issue please do the following.

Place some controls on the front panel and select all and closely observe the space between each controls.

Try to move the objects to the left or right/up or down and you can see there is no change between the objects. Now Press shift and use the arrow keys and you can observer the pixel space between some of the objects are changing.

The distance between the Chart and the color box is atleast more than 1 grid space.

Here the pixel space between the chart and the color box is less than a grid size.

I am sure this is not an optical illusion. 🙂

[AristosQueue (NI)]

Altenbach:

The current behavior exists because people wanted the "align these in this direction" functionality. The "move and maintain relative position" had three other mechanisms, all of which have been noted in this thread: grouping, moving with mouse, and moving single pixel with keyboard. The align request wasn't fulfilled any other way. Do you have a proposal for how that would be achieved if shift+arrow was repurposed?

[Darin.K]

@Intaris - The immediate closing of the idea that the OP clearly spent more than the usual amount of time considering and gathering screenshots bothers me more than the behavior itself.  I happen to agree and would have Kudo'ed it given the opportunity, but I think it deserves a fairer shot than it was given.  And your conclusion that it is "workable" is quite reasonable IMO.  

> The current behavior exists because people wanted....

I do not find this to be a basis for debating the behavior.  Some people do, some people don't.  We could try to quantify it by say Kudos on this idea, but that was stopped despite a clear "this is not a bug" statement.

As you weigh the options and where to assign the pain I think it is fair to consider why people want it and what each decision means to the other group.   The quoted reason in the declining statement is "The shift+arrow keys are meant to keep things on grid boundaries".  Shift+arrow moving one grid space also keeps things on grid boundaries.

So, all I ask is a simple thing which has taken me many words and posts and have yet to achieve:

What scenario leads to the situation which is helped by the current shift+arrow behavior?  

Answer that question with a simple, common scenario, and I will at least feel better.  Given that scenario I would still have to weigh the workaround versus the PITA that is grouping/ungrouping.

I can give many easily encountered scenarios where I end up with a zipper after the move.  Moving with the arrows with fine/coarse control based on the shift-key is very common in other drawing programs, and very effective IMO.  To remove this tool is an annoyance to more than just myself I presume.  I think Intaris finally struck on the perfect word I have found from the proponents, it is "workable".  Straying from a common, effective workflow to achieve something which is "workable".  

What would I do to align to the grid?  A few options I'd consider: 

1)  One of my most-used QD shortcuts aligns selected objects to the nearest grid.  Quickly cleans up those unwanted 1-2 px offset LV likes to create.  This could be an option in the align menu.  Select objects -> snap to nearest grid point.  Future shift-arrow moves of one grid interval keep you on-grid.

2)  Same as 1) with a few options for aligning to nearest horizontally or vertically.  I think 3 is right: hor, vert, both.

tl;dr : Moving with the arrows with fine/coarse control based on the shift-key is very common in other drawing programs, and very effective IMO.   

As for grouping, how does this help me on the BD?

[altenbach]

I still disagree. Shift move should be more like a "gear shift", moving whatever is selected as a group, just faster. For any other alignment (e.g. align bottom edges) I use the alignment tools from the tool bar, because the shift-down-arrow typically does NOT align objects properly. Most often some are slighly below and some slightly above a grid line, making them even less aligned afterwards. It is just disfunctional and not predictable enough. (Darin's align to nearest grid seems more reasonable!). Also most objects have heights that are not multiples of the grid spacing, meaning shift-up after shift-down misaligns things even more. The LabVIEW behavior is the oddball here. A "shift-up...shift-down" of initally perfectly aligned objects often does not end up with the starting configuration. It is not a NO-OP as one would expect.

Moving with the mouse requires <shift> in order to limit to a single direction (OK, I know that, who else?). Moving long distances by single pixels can be very tedious on a slow computer with a large selection. I don't use grouping.

Well, that's just me. The way LabVIEW does the shift-arrow moving causes significantly higher use of ctrl-z in my daily work. 😄

I also would vote for re-opening this idea. 😄

[Darren]

I'll re-open the idea. Kudo away!

[Darin.K]

Now you can close it for real.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Keep-alignment-when-moving-multiple-objects/idi-p/2330...

[JÞB]

Put me in the camp of "I like it the way it is and wouldn't want it to change"  It would be nice though to have the behavior documented.

[JB]

... and me in the camp of "I don't like it the way it is and would want it to change".