The Block Diagram should be the central VI component (not the Front Panel)

[GregSands]

From considering a number of other ideas (see below), I want to suggest that the Block Diagram is the only item initially created when defining a VI, and becomes the place where ALL VI functionality is defined.  The BD is the place where dataflow is specified and the functionality of the VI is determined.  So it makes sense that the con-pane should be linked to the BD rather than the FP -- it defines the data interface between calling VIs to this VI.  Similarly the icon often provides a visual clue to the VI functionality, rather than its FP look.  So both con-pane and icon are natural components of the BD window.

From the BD, it should then be possible to define one, or more, Front Panels which provide user interfaces to the data.  These FPs may contain some or all of the variables in the con-pane (why ever show Error In/Out?), along with some or all of any other controls/indicators used in the block diagram.  In fact, the Probe Window is already almost an additional FP - just allow several data indicators to be grouped on a single window, and you essentially have a Debug Panel.  It would be great to be able to save the Probe window (or several of them) with a VI. 

Yes, there will be problems, not least that I'm sure some existing code assumes that an FP (and only one) exists if a BD exists.  And that every control/indicator must have a FP representation.

Here's a rough mockup (though the Probe points could be "virtual indicators" instead):

Other related ideas:

Be able to link to the connector pane in Block Diagram

Sub VI without Front Panel

Custom Probe Watch Window

We need to uncouple the "edit mode" FP size from the "run mode" FP size

and one trying to address the same concerns, but in a way I don't like:

Add Data layer for VIs... 

[Darren]

Complete in NXG, based on the response of GregS (the original idea author):

"Yes, NXG does have most of this - I hadn't realised that you could define a GVI completely on the Diagram, and leave controls unplaced on the Panel, including setting the connector pane - that's actually really nice.  The one aspect of this idea not covered in NXG is the ability to define more than one Panel per Diagram, where you might save different Debug or Probe views of the same VI.  But that's a secondary part - I think the main concepts are indeed implemented, so I'd be pleased if this was closed off.  Makes me look forward to using NXG a little more now"

[pauldavey]

And now (that NXG is halted) maybe not so completed yet?

[BertMcMahan]

Darren, any chance we could please reopen this one since it was closed due to NXG?

[Darren]

Changing status back to 'New' since LabVIEW NXG was discontinued.

[Petru_Tarabuta]

+1. Diagram-only VIs (VIs without a Front Panel) would constitute a massive improvement to LabVIEW.

I strongly believe that LabVIEW is a "real" programming language. It certainly is Turing-complete (computationally universal). But I can see how the fact that each and every VI must have a front-panel (a GUI) can make LabVIEW seem like a toy language in the eyes of a professional text-based programmer (C, C++, C#, Java, Python, etc).

In a typical text-based application the number of GUIs is much, much smaller than the number of routines (I use this term to encompass the terms methods, functions, and procedures). This is logical and efficient. As examples, why should the following routines have a GUI?

• A routine that takes "a", "b", and "c" as inputs, and outputs "3D_Distance = sqrt(a² + b² + c²)".
• A routine that takes a string as input and removes all the whitespace from the beginning and end of that string (equivalent to Trim Whitespace.vi).
• A routine that reads or gets a field from an object (a getter accessor method).
• And virtually all other routines in a typical application!

These routines do not need GUIs. This is evidenced by the fact that millions of text-based programmers around the world have been implementing these sort of routines happily in their languages for decades without needing a GUI for each of the routines! Moreover, many text-based apps have no GUI at all (e.g. console apps, Windows service apps). This is a perfectly legitimate use case that LabVIEW should support too.

The fact that each and every VI must have a front-panel costs us (professional LabVIEW programmers) dearly in at least the following ways:

• Having to spend a few seconds, a few tens of seconds, or more on “tidying up” each front panel. Tools like pressing Ctrl + U on the Front Panel help a lot but you still need to remember to do it and on occasion they still require the programmer to manually adjust the position of the FP controls and indicators.
• Our applications are bloated. They carry around lots of FP-related state data and/or settings for each and every VI that is part of the application, even for the VIs that will never show their Front Panel to the user once the EXE is built. This is extremely wasteful in terms of memory and disk usage.

Some people say: “I like Front Panels because they help with debugging”. I agree that Front Panels generally help with debugging. I too like using Front Panels for debugging. But debugging is generally a very short stage in the lifetime of a VI. A VI may exist in a codebase for 30 years, out of which it may be debugged for a total of 1 hour. Solution: Give people the option to have a Front Panel or not, and to toggle between the two states. If I need to debug my VI, I will use a Front Panel during the debugging session. Once I’m happy that the VI works well and passes the unit tests I would remove the FP, thus removing the bloat of that VI. Let’s appreciate that text-based programmers have managed to create “small” applications such as operating systems (Windows, Linux) without needing a GUI for each routine they had to debug!

For these reasons, I believe that the fact that each and every VI must have a front-panel is an anachronism. Diagram-only VIs would constitute a significant improvement and would be another step towards LabVIEW being considered a real language, even by professional text-based programmers.

Around six months ago I unintentionally created essentially a duplicate of this idea: Block-Diagram-Only VIs (VIs without a Front Panel). That idea currently has 24 kudos. If possible, I would like those kudos to be merged with the kudos of this idea (45 kudos currently).

Thanks!

[fefepeto_kb]

Just to place emphasis on some of the aspects that are different, yet parallel to the text based languages:

• LabVIEW connector pane acts like the definition of a function/method (VI) that is usually stored in a header file in C, or in the method definition part of a C# class. Currently there is no solution in LabVIEW to edit the connector pane without the Front Panel, which has its own improvement ideas.
• The number of GUIs isn't really smaller in text based languages. The front panel isn't necessarily a GUI. It is not a user interface at all if this does not get displayed. I think the concept of LabIVEW has to be clarified here: it is a graphical programming language, that represents VI parameters graphically. And it takes me back to my previous bullet point.
• I agree that text based languages doesn't need post interface definition cleanup, because they do it while editing the interface (typing it out). I can definitely see tradeoff on both sides.
• The front panels can be mass removed from the built application. It is just a few clicks in the build spec. The advantage of the text based languages here is, that they have a default build description with the debug symbols disabled, usually called release.

I don't say that the BD only VIs don't have value, but if we remove the FP for good, that VI becomes stuck with the interface. Every time something changes around the VI, a new parameter has to be added, an old one removed or changed, it would be a pain to port over the code in a whole new VI. The only way to solve this problem would be to allow FP terminals existing without FP, which seams like changing one of the core concepts of the language.

In general I think being able to hide the FP window, and showing BD by default it is something a lot closer to the intent of LabVIEW.