LabVIEW Idea Exchange

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

New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)

Status: Declined

QuickDrop works well for accelerating this workflow. Also, I want to reserve the key modifiers on the wire-and-double-click gesture for possible future additions of related editor operations.

Recently LabVIEW has added the following feature: When creating a new wire, double-clicking creates a terminal. This can be an indicator or a control, depending on what was selected. If the wire was started from a data sink (a structure tunnel or a subVI or node input terminal), holding down the Ctrl key while double-clicking creates a constant. This is very useful and saves time. Kudos!

 

When working with cluster wires, it would be useful if an Unbundle By Name node could be created by:

1. Start creating a new cluster wire or wire branch

2. Hold down a modifier key (Ctrl, Alt, Shift, or a combination thereof) and double-click

 

Step 1: Start creating a cluster wire

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Notes

  • Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.
  • The screenshots above show a cluster wire being created starting from a control terminal. The gesture should, of course, work regardless of which object the wire branch was started from (e.g. tunnel, subVI output terminal, etc).
  • Perhaps the idea can be expanded to creating Bundle By Name nodes. Perhaps one modifier key (e.g. Ctrl) would create a UBN node, while another key (e.g. Alt) would create a BBN node.
12 Comments
wiebe@CARYA
Knight of NI

@Petru_Tarabuta wrote:

Notes

  • Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.

I don't use clusters a lot anymore (classes replaced them).

 

But obviously (?), this should extend to class wires, at least when you're in the class's private scope:

 

wiebeCARYA_0-1711616933293.png

 

The out of scope behavior could be debated... Maybe simply add an UBN anyway.

Petru_Tarabuta
Active Participant

Fully agree that the gesture should extend to class wires, and that it would be best if the gesture worked for class wires only when inside the class's private scope.

JoGra
Member

Great idea!

 

I also just started using the BundleMagic Plugin Toolkit for LabVIEW

and its so nice (although slightly buggy and sometimes causes crashes) but maybe with some dev from the community it could be come more stable. 

Just the right click -> Bundle/Unbundle on cluster/class/reference wires to get a small ui to select the element is quite a lot faster than the CTRL+Space -> ubn -> CTRL+I and then manually selecting the element. 

Christina_R
Active Participant
Status changed to: Declined

QuickDrop works well for accelerating this workflow. Also, I want to reserve the key modifiers on the wire-and-double-click gesture for possible future additions of related editor operations.


Christina Rogers
Principal Product Owner, LabVIEW R&D
Petru_Tarabuta
Active Participant

"QuickDrop works well for accelerating this workflow." - QuickDrop certainly helps, but it's not quick enough.

Performing the following actions typically takes more than 1 second:
1. Pressing Ctrl + Space to launch QuickDrop
2. Wait for QD to launch (this is the slowest part of the process and may take more than 1 second)

3. typing "ubn"

4. Pressing Ctrl + I to insert

5. Wait for the insert action to finish (perhaps under 0.2 seconds)

 

Compare this with a text-based language, say C#, where all a programmer needs to do to access a field of a structure or an object is to type a "." character. One character. For example, foo.field1 accesses "field1" instead of the whole "foo" structure or object. This is the efficiency standard that LabVIEW needs to compare itself to.

It may sound like I am splitting hairs - "Yes, it's quicker to type a "." than to spend two seconds using QuickDrop, so what?". The impact comes from this being a repetitive action that a professional programmer may execute dozens, even hundreds of times per day. Those two seconds add up to minutes, then hours, then dozens of hours in a programmer's career.

"Also, I want to reserve the key modifiers on the wire-and-double-click gesture for possible future additions of related editor operations." - Could you be more specific please? What do you mean by "related editor operations" exactly? Are these related editor operations on the roadmap, when will they be delivered? Was declining this idea your decision only ("I want to reserve...") or was it discussed in a larger group? Was the 22 kudos that this idea accumulated in a relatively short period (5 months and 1 day) not enough to convince the team that people want this?

Darren
Proven Zealot

Petru, I'd like to figure out why your Quick Drop is taking more than 1 second to launch. If you're in LabVIEW 2023 Q3, make sure you've installed Patch 1, which fixes a bug in Quick Drop that caused slow launch. If not, then try mass compiling the resource\dialog\QuickDrop folder, maybe something is messed up in your compiled object cache for Quick Drop.

 

To your other points, I tend to agree with Christina that reserving key modifiers for certain classes of editor gestures would be preferable to having LabVIEW R&D define a bunch of disparate modifier actions for different object types.

 

And if that never happens, another more general idea would be for R&D to allow us to write LabVIEW code to hook into different editor gestures, kind of like right-click plugins and Quick Drop Ctrl-Key shortcuts, but for key-modified left-click gestures. That would be cool, because then we could customize the behavior ourselves and build a plugin community around them.

Petru_Tarabuta
Active Participant

Hi Darren,

"I'd like to figure out why your Quick Drop is taking more than 1 second to launch. If you're in LabVIEW 2023 Q3, make sure you've installed Patch 1, which fixes a bug in Quick Drop that caused slow launch. If not, then try mass compiling the resource\dialog\QuickDrop folder, maybe something is messed up in your compiled object cache for Quick Drop." - Thanks for the genuine concern and for the advice. I have just launched QuickDrop multiple times from a blank new VI (outside of any project) on the machine I am writing this message from. This machine is a powerful desktop running Windows 11 64-bit and LabVIEW 2024 Q3 Patch 1 64-bit. You are right - QuickDrop launches in much less than 1 second. In fact, it launches virtually instantly. This is good. Recently I've been doing most of my work on a different machine - a less powerful laptop, but running the same software configuration, namely Windows 11 64-bit and LabVIEW 2024 Q3 Patch 1 64-bit. I suspect that QuickDrop launches ever so slightly slower on that laptop (I'd have to test), and that's partly what formed my impression that it can sometimes take as long as 1 second. When using QuickDrop for real work on that laptop it is typically launched from VIs that are part of a large project that contains a few thousand VI and CTL files, and that depends on more than a dozen VIPM packages. I'm mentioning this just in case the size/complexity of the codebase and of the dependencies affect the QuickDrop launch performance (not sure if it does). To get an accurate measurement I would like to, one day, record my screen on both of these machines while launching QuickDrop in various circumstances, and then watching the screen recordings to count the number of frames it took for QuickDrop to launch in each case. This would provide an accurate measurement, but it is a lot of extra work that I can't take on right now.

 

In short, I accept that inserting a UBN node into a wire can be done in between 0.5 to 1 seconds (for all 5 steps listed above). This does not invalidate the argument, which is that it is much quicker to type a single character (the "." character) in a text language - requires a single keystroke - followed immediately after by a helpful drop-down list of field names to choose from (in Visual Studio at least), than to use QuickDrop to insert a UBN node followed by selecting the field that you need using the mouse. In other words, we (professional LabVIEW programmers) could use a quicker method of performing this routine operation (and several other routine operations such as the ones mentioned in a few other ideas I posted this year).

"To your other points, I tend to agree with Christina that reserving key modifiers for certain classes of editor gestures would be preferable to having LabVIEW R&D define a bunch of disparate modifier actions for different object types." - Standardisation is normally useful. But it also makes sense for the editor to behave differently depending on context. When working with cluster wires, it makes sense to facilitate the creation of UBN and BBN nodes. Same when working with class wires, but only when access scope rules allow it (a different contextual awareness). And, for example, when working with DVR wires the same gesture might introduce an In Place Element structure with DVR Read/Write Element already included (this is just an example for the sake of argument, I haven't thought it through to understand whether it would actually be a good idea). Programmers would understand these different behaviours, because they are relevant to each context.

 

"And if that never happens..." - That's my worry. That good ideas that are upvoted by a fair number of people simply get turned down in favour of some elusive, ten-years-from-now grand idea that will never happen. That we are making the perfect the enemy of the good.

 

"...another more general idea would be for R&D to allow us to write LabVIEW code to hook into different editor gestures, kind of like right-click plugins and Quick Drop Ctrl-Key shortcuts, but for key-modified left-click gestures. That would be cool, because then we could customize the behavior ourselves and build a plugin community around them." - Couldn't agree more. Opening more hooks (including key-modified left-click gestures) to the community would do wonders, just like opening the QuickDrop plugins and Right-Click menu plugins did.

Darren
Proven Zealot

> I'm mentioning this just in case the size/complexity of the codebase and of the dependencies affect the QuickDrop launch performance (not sure if it does). 

 

It does matter. Quick Drop lists all VIs, typedefs, and classes that are in the currently active project. We're pretty darn fast in generating that list (if I do say so myself), but yes, thousands of VIs in a project could affect Quick Drop's launch time. I will say that I regularly work on projects with thousands of VIs, and I can discern a *slight* increase in launch time, but not enough that it impedes my workflow. Certainly not close to 1 second of delay...

JoGra
Member

Does Quickdrop save the generated list somewhere?
Sometimes it takes a couple of seconds to open when I press CTRL+Space for the first time after loading a project, but any time after its as fast as usually. 
So that's not really a problem.

 

Ontopic:

Since LV2023 we have the new right click menu when creating a new wire. Maybe that menu could be extended with wire specific options like "Create Unbundle" for a cluster or class wire.

JoGra_1-1725012108815.png

I will have a try a creating QuickDrop plugin to lunch the BundleMagic Plugin.

wiebe@CARYA
Knight of NI

>Does Quickdrop save the generated list somewhere?

 

Yes, in memory.

 

The first time the list is populated (takes time), the next time the stored list is used (fast). It seems the list is maintained after creation, but there are actions that cause the entire list to be recreated. It's not just the first time it's slow(er)...