Variable pixels for Shift+Arrow

[JÞB]

For about a decade and a half I have consistently changed the default block diagram grid spacing to 4. Why, to match the shift arrow moves.  Hold it!  Why not make the shift arrow moves equal the grid spacing?  

Yes, I a genius!  The Kudos button is lower left!

[elset191]

---

@JÞB wrote:
Visual noise reduced with transparency setting. On for visual indication of run / edit mode or, clone, or locked / checkout.

---

Seconded

[AristosQueue (NI)]

> Now, I'll ask "If CEIP data shows a very low percentage of users using bd

> grid, why haven't you fixed the default settings so that people who turn it

> on aren't annoyed?"

Because the overwhelming feedback has not been, "Oh, please fix this." It's been, "I see no point nor any changes that would make it have a point. Why did you waste your time making a diagram grid in the first place?" This question was revisited for NXG, and they got the same answer. NXG just fixed the sizes of things on the diagram, eliminating even the most cursory need for an alignment grid there.

[James@Work]

Priceless

"If we do any work on the block diagram grid, it will be to eliminate the feature entirely. Be careful what you ask for."

Translation - If you don't like the way we want to play the game we'll take our toys and go home.

Too many times this is the NI response when an idea for improvement doesn't fit their internal team viewpoint.

[AristosQueue (NI)]

James@Work: I consider that to be an unfair characterization in this case. 

Input 1: As the person who created the grid, I get all the feedback about its functionality that has come in over the last 18 years. I get many customers saying, "Why did you even bother to build the diagram grid?" They don't suggest improvements... they don't think it serves any use at all. This is actually why LV NXG is designed without a grid: the grid as a concept is broken. What was needed is a complete change to the physical structure of nodes to solve the problems the grid is designed to address.

Input 2:  Maintaining the current grid behavior is actually quite cumbersome when we are adding new features. It requires updating code for two different layout paths, one with the grid on and one with the grid off. Keeping it working has slowed development of several features, notably live drag recently.

Conclusion: If the grid is widely unused and considered not merely deficient but actually a bad idea, AND if it is interfering with other features that are more widely requested, then ditching it becomes a better decision compared to trying to improve the grid.

Every time I hear someone talk about a new reason why the grid doesn't work for some user in its current form, I inch closer to saying, "Look, there's nothing we can do to fix a fundamentally flawed idea... patches like the one suggested in the Idea are just band-aids on a gushing wound. Let's put it out of its (and our) misery. Let LV NXG do it right." I don't expect to kill it, but if it gets in the way of development one more time, it might.

[James@Work]

I like/want the functionality of the grid, but I don't want to see it!