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. 🙂

[fabric]

> > Shift-Arrow should move objects by one grid interval. 

> Thank you for your opinion. Your opinion is not shared by other users.

FWIW Darin's opinion is shared strongly by me, and I'm a user. I would love to see LV come more into line with other modern interfaces for graphical object manipulation.

The "force everything onto the grid" approach might work better if labels/captions were ignored and alignment was based on the body of the control, but that's another rant...

[Intaris]

@Darin,

Grouping is inferred by selection, no need to group them explicitly.

while the required functionality IS provided by grouping elements first I think a method of accelerating the action of declaring to LabVIEW "This is a group, not a selection of individual items" could be interesting.  I personally would miss the ability to align multiple objects individually on my grid.  I use this quite a lot.

Having said that, generally speaking, if elements have a defined spacing to each other then they SHOULD be grouped since you don't know what kind of grid someone will have in their INI file when opening your VI.  In order to maintain your precious arrangement, grouping is exactly the tool required.  Otherwise the user might need to re-position something, only select a PART of what you have defined as being a group and then re-position.  Then, even with your idea i mplemented, your spacing is gone.

[Darin.K]

>  I personally would miss the ability to align multiple objects individually on my grid.  I use this quite a lot.

I am curious how you end up with multiple off-grid objects, yet still arranged remotely usefully for a simple nudge of each one to be useful.  Anything you place with the mouse on the FP will be aligned.  That leaves the crapshoot that is the FP placement of objects created on the BD.  This algorithm of course disregards the laws of nature along with your grid settings.  When this happens to me there is no perturbative solution (ie. nudging them all to the grid), they have to be placed in their desired location which is a grid respecting mouse drag.  Is this a real problem that this behavior is solving for you or is there some other bad behavior of LV that this behavior is helping to mitigate (do two wrongs make a right here?)

> Having said that, generally speaking, if elements have a defined spacing to each other then they SHOULD be grouped since you don't know what kind of grid someone will have in their INI file when opening your VI. 

Grids and such are a VI-based setting, not an IDE overridable setting, the IDE only controls the setting for new VIs.  My grid ships with my VI so nothing is moved just by openning it.  Grids are a placement aid only, nothing more or less, simply constraining drop locations for future drag and drop operations.  

Also, let me remind you of the transitive property.  If I want A and B to be aligned at the top then I SHOULD group them apparently.  Now I want A and C to be aligned on their left edges so I SHOULD group them as well.  Of course if A is grouped with B and A is grouped with C, then two unrelated objects B and C become grouped as well. 

But regardless of what I think it should be or you think it should be or any handful of people think it should be, the real question is what is it EXPECTED to be.  And what I propose is not only based on what I think it should be it is based on what I expect it to be from having used AutoCAD, Illustrator, Photoshop, Keynote, PowerPoint, and on and on.  To go against the grain so much is a very bad UX decsion unless there is an obvious, compelling reason to do so.  I have yet to hear that reason (which is why I asked how you find yourself using this).

[dthor]

>> the real question is what is it EXPECTED to be

I expected it to align each item individually to the grid, and then subsequently move each item by 1 grid spacing. Which is exactly what the current behavior is.

I don't know where I got that expectation from, but I do remember being pleasantly suprised when I first did "select many + Shift-arrowkey" so many years ago. My reaction was along the lines of "Oh good, it aligns things to the grid first."

[jcarmody]

>>  My reaction was along the lines of "Oh good, it aligns things to the grid first."

My reaction to this thread was "Oh, OK.  That's explains the annoying behavior I've seen all my life."  Well, at least, now I know to group things first.

[elset191]

I don't use the grid settings, but if I did I would expect (and desire) it to work how Darin is saying it should. 

[Intaris]

@Darin,

Go to your settings and change the grid spacing.  Voila, you have a ton of objects no longer aligned to the grid.

But really, this is a non-argument.  The fact that objects CAN be off grid is just that, a fact.  Trying to make the point that it's all my fault for being so stupid to even HAVE objects off-grid is an argument that's going nowhere really fast.

I reiterate my previous statement.  If objects on your FP should maintain constant spacing to each other, group them.  End of story.  How on earth should someone else who opens your VI know that this spacing is sacred if there's nothing there to tell them.  But if they're grouped then the passing on of this information is secured.

[Darin.K]

@intaris

Bigger grid:  much worse, that label that sits 1 pixel to the right of a grid line will suddenly jump even farther.  And given the disconnect between how LV treats labels, increment/decrements etc. and how I like to align things means there is no useful.  Graphic layout is not about absolute positioning most of the time, it is adjusting and maintaining relative relationships.   So natural with most drawing programs, not with LV.

When did I say it was YOUR fault.  All I said was that you seem to find yourself in the situation with off-grid objects.  LV makes it very easy to do that since practically every thing placed via pasting or create control/indicator is off grid (which for me is the smaller issue compared to its random location).  All I said was it happens, not how it happens.  If you feel better I think it is LV's fault, not your fault. 

Allow me to reiterate my previous objection, grouping obeys the transitive property, and a previous, previous statement that it is a PITA unless the FP is rather large so the menu is visible.  Other programs allow you to group and still with a special tool work within the grouped objects without the ungroup/group or group/ungroup dance.

Again, out of curiosity, what situations lead to a problem with many off-grid objects which is solved by realigning them en masse?  And what other drawing software does something similar?  I realize that you may be amongst a large group that uses LV 99% of the time, some of us aren't and these inconsistencies with other programs cause aggravation and in some cases I see no mitigating gain.  You think it is great, I am curious as to why?

[Intaris]

You think it is great, I am curious as to why?

I don't think it's great.  I think it's workable.  I'm not completely against the proposal of changing the behaviour because I'd probably have as much use for this idea as the existing behaviour.

What I don't get is the insistance that relative positioning of objects on the FP is really important and must be maintained but nobody seems to think that grouping them will solve that problem.  That's exactly what grouping is for.  For me personally, this part of the argument is extremely weak.  See my previous post where I mentioned the imporatnce of the positioning not being reflected in the state of the FP.  This can still lead to someone unwillingly moving PART of your controls (especially if some are sometimes hidden).  Grouping solves all of that.

If that's really what's bothering you then I'd suggest considering what it is about grouping that's so unusable and propose that change instead.  Because if that was workable this siggested idea becomes irrelevant.

[altenbach]

I am actually with Anand here. I also don't like the current behavior where objects are aligned individually if they are selected together (not grouped). If we shift-arrow move a set of selected objects, the frontmost (in the direction of the move) should align with the grid and all other selected objects should keep their relative position to the frontmost object.

I have never encountered a situation where I want to change the relative position of selected objects, but this invariably happens with shift-arrow moves and I always have to immediately "undo" and either move the group with the mouse or one pixel at a time.

I would welcome if this could be changed.