Clusters as a concept should only exist on the block diagram

[Mads]

Clusters can be a useful tool for the programmer. Its role is on the block diagram. On the front panel the cluster's only useful feature is better served by grouping and decorations.

-Clusters force you to have all the controls within it bundled together within a box on the front panel. A box that even interferes with keyboard navigation. If you want one of the controls to be located elsewhere, you have to choose between the usefulness on the block diagram, and the best design of your user interface. The link is just unnatural.

 I can understand the philosophy behind the current solution. It maintains a coupling between the block diagram and the front panel that is consistent with much of how other parts of the IDE works.

However, once you have established that clusters only exist on the block diagram, the need for a front panel representation of it quickly vanishes. There should be a way to get an indication on the front panel of the controls  that are bundled together. It should be obvious to the programmer that deleting a control that is defined as part of a cluster will affect the cluster on the block diagram etc., but not much is needed to achieve this really.

Breaking artificial couplings are always good, but never pain free. They break old habits. But the end result would be a more flexible and intuitive solution for both programmers and end (application) users.

[AristosQueue (NI)]

> I have never been a fan of the idea that we should discourage bad habits by making things less user friendly though. 

Me neither. The trick in this case is that I cannot propose any automated mechanism for keeping the cluster definition and the UI definition up-to-date precisely because I don't think they *should* be kept up to date. In other words, to me, the *majority* case is that the cluster definition and the UI definition have little to nothing to do with each other. In other words, I would favor proposals that made it easier to build user interfaces, but not ones that relied on the cluster def and the UI def being tied together. As an example, if you were to propose a scripting tool that allowed you to point at a cluster typedef and point at a VI's front panel and then specify a mapping between the controls ("these two cluster values combine to set this one panel control, this one panel control maps directly to this cluster value, etc") and then generated the block diagram code to make that happen, I'd probably support it, or something like it. But after the tool ran, there's not a relationship between the cluster and the UI (maybe a metadata file saved off to the side to aid in rebuilding the UI if you change the cluster). I'd favor an *editor* solution to this problem, not a *language* solution to this problem.

> If clusters do not generally belong on the front panel they should be

> removed completely from the control panel

No. Here you go too far in my opinion. Clusters do belong on non-UI panels. The vast majority of front panels are not end user panels. The majority of panels are critical as test panels for learning how a function works and as debugging tools. Just like variants and array controls belong on the front panel of non-UI controls.

There is a fundamental difference between a UI panel, where you are rearranging the elements to make a display for an end user and a non-UI panel that is not part of your final application.

[Mads]

The last part is easy enough; I want us to be able to define clusters on the block diagram, and link them to the connector pane without ever going to the front panel. This way you will never really need clusters on front panels, not even for non-UI panels.

However, the second part of the idea is that you *can* still associate front panel controls with your block diagram cluster *without* having to establish that link by bundling wires from the terminals of those controls.

If there is a control on the panel which value should flow out of a cluster terminal, you can associate that control with the equivalent terminal within that cluster on the block diagram.

A behind the scenes bundle... It might sound strange, but I think that it could be made in a way that would feel very clean and natural. In fact I do not think anyone would ever miss the old cluster on the front panel...Today's solution would seem ridiculous.  But I'll probably need to make a demo to convince anyone of that

[AristosQueue (NI)]

Would you want to make that association on every subVI? I wouldn't. On most VIs, I just want to create the cluster and go on.

[Mads]

No, there is no need to set up association to any front panel objects unless you want to.  The cluster  "lives" perfectly fine on the block diagram alone, where it flows from VI to VI through the connector pane (now available on the block diagram, where you link terminals to it instead of controls/indicators).

If you do want to modify the content of the cluster from the front panel you can choose to have some or all of the terminals within the cluster associated with controls on the front panel. These associated controls can be moved independetly from eachother because the association is set up from the block diagram, not by having them in a container on the front panel.

If you edit the cluster typedef and delete a terminal that currently has controls associated to it on some front panel, those VIs will break until you remove the association or delete the control. The other way around is a case where you delete a control that was associated with a cluster.  This would produce a warning. The warning could perhaps also give you the option to actually apply the delete on the cluster it was associated to as well, but I'm not decided on that. Perhaps it would be cleaner to say that if you want to change the cluster it has to be done from the block diagram only, because that is where the cluster really exists.

Creating a cluster in the first place can be done in many ways. Today you create a container on the front panel and drop the controls into it. With clusters as a block diagram concept only (the association feature is a side-idea) that container will be on the block diagram, and you can drag terminals into the container to add or remove them from the cluster definition. If the cluster has been typedef'ed you do as today - you have to go to the typedef edit window to be able to do any changes...

[AristosQueue (NI)]

Ah. There's the difference between your world view and mine... *every* VI in my world *needs* a front panel. I use most of them during development. Having the cluster as a diagram-only entity woud keep me from seeing it. Also, there are times when I want to move clusters of data around by reference -- so I need a single control reference that can hold the full cluster of data (yes, DVRs also work for this, but the static declaration is often way easier to set up than the managing the lifetime of the DVR). Basically, all the reasons why variants, refnums and classes would ever be on a front panel still apply to clusters. At the borders to subVIs, the cluster really exists on the panel as inputs and as outputs and as local variable declarations.

[fabric]

---

@AristosQueue (NI) wrote:

Ah. There's the difference between your world view and mine... *every* VI in my world *needs* a front panel.

---

One interesting observation is that controls on front panels of sub VIs have started to become somewhat like vestigial tails in many modern architectures - during runtime at least:

• Inlined VIs don't update their panels, so you could argue that the FP is entirely irrelevant at runtime.
• Clones by default don't show their panels unless you force them to - generally by adding breakpoints in the parent or stepping in from a caller. Once you "enter" a clone it is often easy enough to add probes since you are anyway in the diagram. Switching to the front panel to check some indicators is arguably just an extra step...

These special cases likely affect AQ more than most, given his affinity for AF and class-based architectures 🙂

[Mads]

AristosQueue wrote:

"Ah. There's the difference between your world view and mine... *every* VI in my world *needs* a front panel."

Today they do, but that's more a consequence of how the Virtual Instrument-concept has been kept unchanged. Other parts of LabVIEW, and the use of LabVIEW has moved forward. The VI-abstraction is limited. Sticking too rigidly to it is turning LabVIEW into an ever-growing pile of compromises. There are many requests here on the Idea exchange that call for a change to that philosophy.

AristosQueue wrote:

"Clusters, classes, variants, refnums, and enums should only be on programmer-only-visible panels."

Or we could eliminate the need for that by allowing terminals to link to the connector pane directly...(Yes, it would be more complex than that to set up a complete replacement of today's front-panel based handling mechanisms, but I do not think it would be Pandora's box).

[AristosQueue (NI)]

> Today they do, but that's more a consequence of how the Virtual Instrument-concept has been kept unchanged.

No... I mean into the future as well. Even if I could link terminals to the conpane (and that is a good idea IMHO) does not eliminate my belief that we should always have the panel available for all VIs. This is not the same as saying it is always loaded into memory, but it is always present and available to be called upon during debugging for "suspend when called" to change values or to just to "enter values, hit run" testing, or even just to watch results as they come through a program.

> Sticking too rigidly to it is turning LabVIEW into an ever-growing pile of compromises.

I could not disagree with you more on this. Changing the priority that the editor places on the panel's existence does not equate to removing the panel's existence from virtual instruments. I've commented more thorougly on that topic on some of the ideas to which you allude.

[AristosQueue (NI)]

> Inlined VIs don't update their panels, so you could argue that the FP is entirely irrelevant at runtime.

And I continue to decry this as a serious bug and a hindrence to debugging. They are entirely irrelevant in the runtime engine. That's not the same as my dev environment!!!

My strong support for panels on all VIs has little to do with the AF but a lot more to do with my exposure to C++ and C# where I *don't* have the abiity to run every individual function nor do I have the ability to easily put some test values through a function and see the results. I constantly chafe at that lack when I'm working outside of LabVIEW.