From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
AristosQueue (NI)

Icon editor could suggest glyphs to include based on VI contents/properties

Status: New

There are suggestions on the Idea Exchange to annotate subVI nodes with various attributes (this one, for example). I think that's a losing strategy. There just isn't space for all the annotations that might be of interest on a given node, and not all of the annotations make a difference to user's understanding of a given node. As an example, knowing that a subVI is reentrant is very important to understanding how a point-by-point read subVI works but unimportant to understanding how Trim Whitespace works. Also, not all of the annotations that we could imagine are simple "on or off" settings. A subVI that uses a local variable might be using it in an iterative algorithm or might be using it to store state between calls. If it is storing state, that might be something that a caller should know about.

 

These are the sorts of things that could be scanned for on a VI when LabVIEW launches the Icon Editor. If we had standard glyphs for interesting attributes of a VI, LabVIEW could have a section to recommend glyphs to add to the icon. This would not be an automated "always add this glyph" system that some people have requested because I do not think that we want the glyphs on every node just because it has the attribute. But some nodes it is worth calling out, and putting it in the Icon Editor would make it easy to add such glyphs. We might even have a fast "add recommended and arrange layers" button that spills all the glyphs onto the icon and then moves them around to minimize overlap, taking the existing layers into account.

15 Comments
Mr._Jim
Active Participant

Hi AQ,

 

(Usually this sort of questioning is the other way around! Smiley Wink)

 

So to summarize, you're suggesting a feature to facilitate adding standardized glyphs that indicate attributes or properties like reentrancy?  This would then allow a user to identify those attributes at a glance when the VI is called as a subVI?

 

The local variable usage to store a state seems like an odd one to me (Unfortunately I've seen it, though).

Do you have any other examples of attributes off the top of your head that you think would be useful to be displayed as glyphs?

 

(Hey, I'm already voting for it, but seeing more attribute examples can only bolster support for the idea)

JB
Trusted Enthusiast
Trusted Enthusiast

Very interesting idea !

 

I'm used to add this self-made glyph to the title bar of reentrant VIs.

 

Glyph reentrant.jpg

 

Manzolli
Active Participant

Following AristosQueue's original idea, I would like to suggest two new categories in Icon Editor (Icon Editor -> Glyphs -> Category):

 

  • Suggested Glyphs
  • Last used Glyphs
  • All Glyphs
  • Acquiring and ...

or 

 

  • Suggested
  • Last Used
  • ------------------
  • All
  • Acquiring and ...
André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
JB
Trusted Enthusiast
Trusted Enthusiast

Manzolli a écrit :

Following AristosQueue's original idea, I would like to suggest two new categories in Icon Editor (Icon Editor -> Glyphs -> Category):

  

  • Suggested
  • Last Used
  • ------------------
  • All
  • Acquiring and ...

Yet a very good idea. This would be very useful.

Intaris
Proven Zealot

It would have to be user-extendable because I regularly use other glyphs which I have sourced from elsewhere.

 

I would like to have the ability to add suggestions to certain conditions found when analyzing the VIs.

AristosQueue (NI)
NI Employee (retired)

Intaris: The existing glyph library is already extensible, so that part is handled. I presume. Connecting in a VI Analyzer callback should be straightforward. Good suggestion!

 

Mr_Jim wrote:

> So to summarize, you're suggesting a feature to facilitate adding standardized glyphs

> that indicate attributes or properties like reentrancy? 

 

Yes. Instead of LV trying to be clever and autoadding such glyphs, I'm suggesting a way to make it easy for the user to add them at his/her discretion.

 

> This would then allow a user to

> identify those attributes at a glance when the VI is called as a subVI?

 

Yes. The absence of a glyph would not indicate an absence of the attribute, which is a drawback to this scheme, but I think it may be a better approach than trying to cloud them all onto the icon all the time. I posted the idea to see what the community thinks of that.

 

> The local variable usage to store a state seems like an odd one to me (Unfortunately I've seen it, though).

> Do you have any other examples of attributes off the top of your head that you think would be useful to

> be displayed as glyphs?

 

State is the biggest one for me, personally. Reentrancy and dynamic dispatching have both been frequently requested. Execution system is rarely used, but having standard glyphs to indicate it would be useful, IMHO.

 

The second biggest for me would be the yellow *. For Open nodes, we frequently have the yellow * glyph to indicate "this node creates a reference". I always try to tag nodes that originate a reference by wrapping Open nodes with that star. Having it as a reminder in the icon editor would be a good idea. Similar for Close wrappers so that I know "this function doesn't just take the reference, it also disposes of it."

 

PS: To anyone reading this, I have no idea if this idea will ever see fruition... this is me posting as a user, not as part of R&D. I don't work on the icon editor anymore -- I cut the hole to make it user-extensible, but the actual extension therein is someone else's doing. 🙂

JB
Trusted Enthusiast
Trusted Enthusiast

I'm really surprised by the little support that this great idea has received until now.

It would for example be so useful if a customable glyph automatically (dis)appeared on the icon according to the reentrancy of the VI.

fabric
Active Participant

@JB: There are way too many quirks with the existing icon editor for me to get behind adding new features right now...

JB
Trusted Enthusiast
Trusted Enthusiast

@fabric: Removing the quirks while adding new features, or the opposite, would be great !

AristosQueue (NI)
NI Employee (retired)

JB wrote:

> It would for example be so useful if a customable glyph automatically

> (dis)appeared on the icon according to the reentrancy of the VI.

 

Doing any of it automatically is explicitly what this idea is rejecting. If you want automated modification of the icon, go kudos one of the other ideas. This is a counteroffer *against* automatic icon augmentation.