Subdiagram label for Block Diagrams too

[francois-normandin]

The mother of all diagrams, the Block Diagram, does not have a subdiagram label...

[AristosQueue (NI)]

Speaking as one rep of LV R&D: Some users might find it useful. There's no reason we couldn't do it.

Speaking strictly for myself and definitely not for all of LV R&D:

---

@francois-normandin wrote:
Why is the Block Diagram the only diagram that does not have a "Subdiagram Label"?

---

Reason 1: Because a comment that doesn't move around and is always there will be in the way and permanently waste space. I assume you don't want this label to be the width of the diagram, running off the screen. So instead, it's some kind of floater over the diagram... like the permanently docked palettes in NXG (those are on the side, not the top, but the principle is the same). But whereas the palettes have some utility, I think this does not, and I would oppose adding it. Also, the palettes are dismissable. Presumably this is stuck visible deliberately. "But, AQ, you don't have to use it. Those of us who want it can use it." Yeah, but when someone else writes it, I have to read it, just like the annoying wire labels that block out the wire and just create visual discontinuity in the diagram. This would start showing up in places from people who don't share my intense dislike for any sort of permanent sidebar/topbar/bottombar floater thing in the diagram space.

Reason 2: Because it is a subdiagram label. You don't put subdiagram labels on a not-subdiagram. 🙂

[drjdpowell]

Suggestion: have this new label show the first line of the VI description.  When the programmer clicks on it, have it expand temporarily to show the whole VI description, and have edits here update the description.

[Hooovahh]

I voted for this initially thought it was a good idea.  But now that I think about it I am less enthused.  I don't mind if a label is taking up space and always there on the block diagram.  The Developer choose to do this, and as a developer myself I can show or hide it all I want.  For me this is the same reasoning as it is for all sub diagram labels today.  Why is this stupid thing taking up precious block diagram space?  Well the developer that made it visible thought the added documentation was worth it and if I disagree it takes one right click to turn it off.  Same here.

But the real reason why I'm less enthused is because the VI Description sorta already is meant for describing what the function of a sub VI is.  In most cases that I would see myself using this it would be for a subVI never intended to be seen when running and putting in a couple lines of text there doesn't take block diagram space away.  This also has the added benefit of being able to be seen from the subVI icon with context help open.  If this were implemented I would have to open the subVI then go to the block diagram and read the label.  I still voted for it, I still think it should be there, but I'm not sure I would use it.

[wiebe@CARYA]

To me, the VI Description is more about how to use it, as a sub VI. The diagram description could be more for the programmer maintaining or changing it.

The VI description is already quickly available, by hoovering over the icon with help on. So flashing (part of) it in the diagram wouldn't add a lot.

Perhaps a toolbar icon with an editable description as a tooltip? Hoover over it, you get the text as a tooltip, press it to edit the text (a shortcut to a new entry in the VI Properties dialog)?

[Darren]

If I want to know what a VI does, I hover over the VI icon in the top-right and read the context help. This is something I'm happy to read once or twice, but I see minimal benefit in seeing it all the time on every diagram.

[drjdpowell]

Most subVIs ever written have no VI description.  So a way that such a description is both immediately noticeable and easily writable and editable is an advantage.

[normandinf-cnrc]

@AQ: I totally expected reason #2. It's the logical answer... 😊

For all the other comments: 

The point of this banner is that it looks better if it stays where it is than if it is tethered to the diagram's origin. Scroll the diagram by a pixel and it suddenly feels misplaced. My use case is when I make example code (such as the one I showed on LAVAG) or when I have a Tree View showing all the public API. When I develop code intended to be used by myself, I don't want this extra stuff, never.

I've used this setup very sporadically in the context of getting the developer watching the block diagram to really focus on something important.

Playing devil's advocate with myself, I could say that if the developer wants to move it around, he's free to do so. Me, I know better than to change the origin of my own block diagram...

[wiebe@CARYA]

>Darren wrote: If I want to know what a VI does, I hover over the VI icon in the top-right and read the context help. This is something I'm happy to read once or twice, but I see minimal benefit in seeing it all the time on every diagram.

The point of this diagram label is not to tell what the VI does, but how the code works.

The VI description is for users of the VI, this diagram label would be for maintainers of the code.