Swipe Gesture for panning around on the Block Diagram and Front Panel

[Rick_K]

Panning around the VI using the scrollbar is way too slow. Using the scroll wheel only goes vertical. The Pan tool is nice but I never switch over to it when I should. LabVIEW should support the swipe gesture on the Front Panel and Block Diagram. Swiping is a gesture done by clicking and "throwing" the canvas one way or another (kinda like minority report). The canvas keeps the virtual momentum of the swipe and continue to pan the screen until the user clicks or the screen slows to a stop. This interface is one of the main tennants in iphone navigation for panning through tables, around web pages, and really anything that is larger than the view.

[crelf]

How would LabVIEW know that you wanted to swipe and not select stuff on the BD?  I think what you're looking for already exists in the "Scroll Window" tool, although it doesn't support momentum (which I'm actually kinda happy about - if you really need the momentum feature, then you might want to look at reducing the size of your diagrams).

[Rick_K]

The iphone, Firefox Gestures, and other programs can tell the difference between swipe and and select. I assume that it is something to do with the speed of the click and drag coupled with the direction and linearity of the gesture. I don't think that is a major problem. I also think that the momentum concept is an extremely intuitive and useful way to interact with a 2D canvas of objects. I have certainly been caught "coaxing" my diagram with the pan tool. It is like having a trackpad with the speed turned way down. Finally, if LabVIEW ever gets zoom, diagram size will not affect how much one might have to scroll to get to the end of his/her diagram. 

[JackDunaway]

I agree with crelf about the BD size. I would like to see more of the useful Ideas implemented before this one. However, if panning did support momentum, I would turn it ON at a very low setting (the amount of inertia should be user settable).

[jlokanis]

I think you are all missing the point that your block diagram should not be larger than your screen in the first place.  So, well designed code does not need scrolling, panning, swiping or zooming.

I would like to see the multi-touch features of the iPhone/Mac OSX migrate to all platforms and be used in UI design, however.

BTW: Nice graphic. 

[Rick_K]

I will concede the BD size should not be larger than the screen. I do believe in this design principle and follow it most of the time. I still require scrolling often for one reason or another. Oh well...next idea.

[jacemdom]

BD not bigger than screen size...22 inch widescreen!!!

[smercurio_fc]

---

jlokanis wrote:

I think you are all missing the point that your block diagram should not be larger than your screen in the first place.  So, well designed code does not need scrolling, panning, swiping or zooming.

---

Try keeping that rule when you're dealing with property nodes and invoke nodes with ActiveX or .NET.

[A-T-R]

---

Try keeping that rule when you're dealing with property nodes and invoke nodes with ActiveX or .NET.

---

 In this particular case I agree with you...

[jlokanis]

Yes, .NET nodes are notoriously long.  I try very hard to divide things up into sub-VIs to deal with this, but sometimes you do go off the screen.  Just not enough to make it worth having the swipe or zoom to me.  And having it a bit painful makes me try harder not to exceed my screen limits.  Even though I use a dual 20" monitor setup, I try real hard to keep my VIs to a single monitor's width (and height).

[CrystalTech]

I only find it easy to keep the diagram size within the screen when there is only one state machine present.  I find in some code I need to set up one or two more separately running loops or queued state machines which I place above the main code.  However, I like the swipe idea as an option, but I don't necessarily need it for myself.