LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Petru_Tarabuta

The default front panel Alignment Grid Size should be 10 pixels (instead of 12)

Status: New

Currently the default front panel Alignment Grid Size is 12 pixels. It should be 10 pixels.

 

There is probably a reason why 12 pixels was selected many years ago, but is that reason still valid? Twelve pixels seems like an arbitrary number. Ten pixels would be more logical because is aligned with the decimal system.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

Thanks

10 Comments
crossrulz
Knight of NI

I need a better reason than "decimal system".  What are standard control sizes?  Looking at random controls on the palette, I see a lot of 24 (Fuse Design System, formerly known as NXG Style) and 25 pixel (Modern) heights.  With that information, a 12 pixel grid makes sense (a control being 2 grids).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Petru_Tarabuta
Member

Chicken and egg. Are some of the controls 24 pixels wide because the default grid size was 12 pixels?

Perhaps a scientific way of going about it would be for someone to create a table that contains the width and height of all GUI elements that ship with LabVIEW: Modern, Fuse Design System (NXG), Silver, System, Classic. Then we could judge whether more elements fit better on a 12 pixel grid than a 10 pixel grid.

But even if the result of the scientific investigation above shows that a 12 pixel grid fits better with most existing native GUI elements, the chicken and egg question remains? Is this the case because the elements were designed for the 12 pixel grid? Is there an underlying UI/UX design reason to justify the size of the native GUI elements? Should/could the size of the native GUI elements be adjusted slightly to fit a decimal grid?

raphschru
Active Participant

If there is no real argument for changing this, I would vote against this idea.

 

12 has 6 divisors (1, 2, 3, 4, 6, 12).

10 has only 4 divisors (1, 2, 5, 10).

More divisors means more possibilities to perfectly space and align controls.

 

I'm not saying this is a strong argument, but to me it is stronger than just "align with the decimal system".

fabric
Active Participant

If anything, I would change it to 8px, which is the same increment as a "shift-arrow" on a FP or BD object.

Petru_Tarabuta
Member

"Shift+arrow" moves the object by a number of pixels equal to the grid size, on both the FP and the BD. One way to test this is to set the Front Panel grid size to a large value, such as 50px. The default BD grid size is 16px, so by default shift+arrow moves BD objects by 16 px.

crossrulz
Knight of NI

To be more exact, the Shift+Arrow moves the number of pixels required to align to the grid.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
raphschru
Active Participant

To be even more exact:

 

On the front panel with visible grid*, shift+arrow moves each selected object the number of pixels required so that the border** of its master rectangle*** goes to the next grid notch**** along the direction of the arrow.

 

*If the front panel grid is not visible or if we are in the block diagram, selected objects always move by exactly 8 pixels along the direction of the arrow.

 

**The mentioned border depends on the pressed arrow. Top border for up arrow, Bottom border for down arrow, Left border for left arrow and Right border for right arrow.

 

***The master rectangle is the red frame that appears when dragging an object on the front panel.

 

****To be more precise, going to the next grid notch means going to the next multiple of the grid size, in the coordinate frame of the Pane that owns each moved object.

wiebe@CARYA
Knight of NI

Too difficult to be useful to me. 😎

Petru_Tarabuta
Member

Thanks, raphschru - that's super exact. The BD movement is 8px when the BD gridlines are not shown. When the "Enable diagram grid alignment" environment option is enabled the shift+arrow behaviour on the BD is exactly the same as on the FP. It moves the object such that its border coincides with the next grid line in the direction of the arrow. By default the BD grid size is 16px, so the movement can be larger than 8px when the gridlines are enabled.
1.png

raphschru
Active Participant

@Petru You're right that grid visibility is not enough:

- FP alignment happens when the global option "Enable panel grid alignment" is checked.

- BD alignement happens when the global option "Enable diagram grid alignment" is checked.

- Otherwise, it moves by 8 pixels.

 

So BD and FP can have similar behaviors.

It is just that on a new LV installation, grid alignment is enabled by default for FP, but not for BD (which is good IMO).