LabVIEW Idea Exchange

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

Always display resize handles for structures

Status: New

When working on old code where we may have some large structures (don't start on style, large structures exist and will continue to exist as long as LabVIEW is marketed to non-programmers) which become a real nuisance to work with.

 

If I'm refactoring such code and have significantly reduced the footprint of the BD, I need to go wandering around looking for the vertical middle of the structure so that I can resize it (make it smaller!).  Why don't the resize handles always appear on the edge of a structure where the mouse is if nothing else is in the way?  Why the insistance that only the corners and middles of the edges can be used to resize?

 

The same occurs if I temporarily need more space, go searching for the middle of the structure, resize and go wandering back.  It would be nice if I could take any arbitrary point on the structure edge to resize.  Of course the corners would remain the only places where we can resize in two dimensions simultaneously.

10 Comments
tst
Knight of NI Knight of NI
Knight of NI

Intaris wrote: Why don't the resize handles always appear on the edge of a structure where the mouse is if nothing else is in the way?

 

The obvious answer is that this allows you to select the structure, which is exactly what happens today. Personally, I think I will generally find selecting more useful than resizing, but maybe with a modifier?


___________________
Try to take over the world!
Mythilt
Member

I could see a possible issue with accidently resizing when you just want to select the structure, unless you have to pause a second or two for the handle to appear.

Or perhaps make it so that pressing the Alt key would add a resize handle to the edge of any structure the mouse is currently over, the corner handles would remain.  That way you would not have to worry about tunnels, shift registers, etc being under the handle, if you are pressing Alt, the handle is there under mouse to be used, if you are not pressing Alt, it is not.  Midpoint handles could then be gotten rid of, only appearing when you need them.  Would solve the issue I posted as well, will mention this in my suggestion I think.

 

Kudos

Jon D
Certified LabVIEW Developer.
X.
Trusted Enthusiast
Trusted Enthusiast

The problem brought up by tst is not an issue for windows in MacOS, Windows and probably other OSes. Why would it be one in LabVIEW? The cursor should switch to resize when on the edge, to select when inside the border of the structure (which has a finite, visible width). The current behavior is inherited from the past and needs refreshing.

Mythilt
Member

No, I do not want click inside to select a structure, clicking on the edge makes more sense.  For one thing, as Intaris pointed out, structures that are bigger than the viewed area are a fact of life when you have non-programmers using LabVIEW who don't bother to learn style, its a big enough pain trying to maintain their code later without the worry of accidently selecting said structure without realizing it because the edges don't show.  Also, you unselect a selected object by just clicking on the background, your proposal would mean I have to move the cursor out of the structure in order to avoid selecting the structure instead of unselecting.

Jon D
Certified LabVIEW Developer.
RnDMonkey
Active Participant

The issue I have with the idea of edge dragging and border selecting is that while most structures have some reasonable border width, at least the diagram and conditional disable structures don't, and the for loop structure only has wide borders on the east and south sides. Maybe this would be ok to have only the count node and two borders selectable, but what about those disable structures?

 

I kind of like the idea of holding Alt suppressing resize handles, or maybe hovering over a resize handle for 2-3 seconds without clicking on it should hide it under the assumption that it's something underneath that is of interest? Still another option, show more resize handles along each edge (say 3 or 5), but leave the handles as recessive so that they are transparent when other objects are underneath. That way, if you want to resize and there is a tunnel under one handle, just pick a different handle (hopefully with 3 or 5 of them you'd have at least one that was in the clear).

 

Here's a picture where I highlight possible resize and select regions on the structures (only 1 side shown where it's obvious).

Spoiler
Select vs. Resize on Structures

 

____
Ryan R.
R&D
AristosQueue (NI)
NI Employee (retired)

This option -- to always display the grab handles at any point along the edge -- was worked on by an intern at NI this summer, among some of his other projects to improve UI interactions. When his work was reviewed by UX and some first round users, they found enough issues with the idea to declare that "it might be a good idea but it isn't a slam-dunk-let's-do-it."

 

For this reason, this idea will be left open, but it may not be acted upon until the next round of structure node UX review a couple years from now.

 

The idea ran into difficulty because of the slip factor -- a user tries to click on something and doesn't expect the grab handle to appear and ends up resizing the structure unintentionally.

 

Although we might be able to ameliorate this downside, now that we have "remove space" (ctrl+alt+drag to remove whitespace), the need for this feature is believed by us to be considerably reduced. No, it does not solve all the cases (there are times when remove space is an overreach), but it solves enough of them, in our evaluation, to not be worth the downsides of the always-present resizer unless those downsides can be resolved through more clever interactions.

 

TL;DR: idea is worthy of contemplation, but it isn't as easy as just telling the mouse, "When you're over an edge, become a grow cursor."

RnDMonkey
Active Participant

AQ,

One issue that I have with the "remove space" (not to derail this idea thread, and not that I care enough right now to see if others have raised the issue) tool is that when I remove space inside a structure, things outside the structure get moved too and often in unwelcome ways. This is especially true when there are parallel structures, where the other structures will stay where they are but everything outside of them will be moved underneath them because the space under the structures is being removed.

____
Ryan R.
R&D
X.
Trusted Enthusiast
Trusted Enthusiast

I think I have not explained myself clearly: in your favorite OS, it is a non-issue to select a window or resize it. The pointer automatically switches to the most natural function. Resizing on the edges, selecting inside the window. For objects (e.g. in Power Point, Gimp, etc), the convention is different (for historical reason I presume) and there seem to be hot spots dedicated to resizing. This is what has been adopted in LV for structures, which unfortunately are much richer than just containers. They have shift registers, wire passages, etc. and those do not play well with the above convention.

What I am saying is that structures could be treated like windows are, i.e. allow resizing from anywhere aruond the structure. As far as automating the switch between tools (grabing/selecting), I would suggest doing what is currently the case, i.e. offering the choice to:

- autoselect the tool (off in my case), with the risk of being driven mad in the vicinity of a dense cluster of wire passages, for instance.

- do not autoswitch tool but let the user TAB through the tool palettes (or Space to toggle between "natural" tools for the object & location), with resize being one of the option.

AristosQueue (NI)
NI Employee (retired)

Quick tangent then back to X:

RnDMonkey wrote:

> things outside the structure get moved too and often in unwelcome ways.

 

Yes, that's the "overreach" that I was talking about. No way around it, really... we either move things outside or we don't, and it seems to be slightly more common to want the outside things to move -- not to mention that keeps it consistent with ctrl+drag to make space, where we almost always (it seems) want to move things outside the structure.

 

X wrote:

> in your favorite OS, it is a non-issue to select a window or resize it. The pointer automatically

> switches to the most natural function.

 

 

Yes... because there's nothing else to do on the border of a window. With LV, we have tunnels on the border. That means either widening the border to have a reserved space for grab handles, or not. Even the places where tunnels do not currently exist are places where wiring occurs. Note that I said it could probably be worked out -- we didn't reject the idea, just said there's details to work out.

johnsold
Knight of NI

RnDMonkey suggested adding 3-5 resize handles. Perhaps an alternative is to always place a resize handle on the visible portion of the edge of a resizable structure. When the whole edge is visible the present method is used. When part of the edge is outside the visible portion of the BD window, the resize handle is placed in the middle of the visible portion.

 

Resize Handle.png

 

Lynn