Front panel layers - productivity improvement

[magicbean]

I would love to see the option to place front panel objects on different layers on the front panel. It would work like layers in a variety of drawing and image/vector editing packages and have the following features/advantages:

1. Layers have no physical bounds or visible features of their own - they are an improved facility to arrange front to back ordering of objects on the front panel. Front panel objects on higher layers would always appear in front of those on lower layers. Objects would still be reordered within their respective layers using current 'move to back / front' tools but layer ordering takes priority.
2. There would be the concept of a 'current layer' - all new front panel objects would be placed on the 'current layer'. The default would be the background layer. If the user never created any more layers, the behaviour would be exactly as current LabVIEW and no knowledge of layers would be required.
3. There would need to be a layers palette or similar facility to allow users to add / organise layers and control their properties.
4. Selected objects could be moved between layers with a 'Move to layer...' right click context menu command. There could be modes for selecting items on the current layer only, all layers, visible layers, unlocked layers, selected layers etc... especially useful when dragging to make a selection.
5. Layers could be reordered, locked/unlocked, renamed, made visible and invisible and grouped/ungrouped. This greatly assists with arranging objects whose bounds partially or completely overlap.
6. Optionally, the visibility and/or ordering of layers could be changed programatically. This makes it easy to change the visibility of entire groups of controls and indicators making code smaller and easier to understand.

The current grouping and locking options for front panel objects does help in organising front panels but I believe that the addition of layers would be a big improvement to productivity. Programs such as Photoshop, Gimp, Illustrator and many others have very excellent layer management which is simple and intuitive; I spend quite a lot of time fiddling with LabVIEW front panel items in a way that would be easily accomplished with the above scheme.

[johnsold]

I think this idea has enough merit to generate some discussion.

I think Item 6 is a mistake. Layers should be for the development environment only. Use a tab control or property nodes for programatic control.

Alignment of objects on different layers should be easily managed, although I am not sure how to implement this. All layers or the current layer only are easy.  Layers 1, 3, and 7 - not so easy, particularly if some other layers are also visible.  Some kind of "anchor" or "reference position" objects which can be placed on one or more layers and do not move relative to the panel origin could be useful.  these are found in most of the drawing programs I have used.

Lynn

[Peti]

I'm using Tab Controls for this purpose.It really helps me, keeps front panel organized.

The tab names are, what that tab contains. For example,in my laser setup,

-tab "temperature" contains all the thermometer settings, and a big chart.

-I have another tabs for Frequency of laser oscillator, etc...

-and data saving is another tab.(Queue usages by the measurement data in progress-bars, file name, and commenting implemented here.)

-Another 2 tabs are created for spare space for new devices.

[Manzolli]

@ Peti: Tab Controls are a great help, but there are some cases that layer could do a better job. Suppose that you have a Tab Control with 5 tabs. Controls that need to be placed in more than one tab force you repeating in each tab or put it outside the Tab Control. Worse if you need only in couple tabs, then putting outside is not a viable option.

With layer the programmer is not restricted to a rectangle that can only be shown one at time. Kudos!

[magicbean]

@johnsold (Lynn): I'm not sure that programmatic control of properties is a bad idea unless it makes the implementation messy from the user's point of view. Using tabs to control visibility (or other properties) has some drawbacks, not least that you have to have the tab control visible in order to see the front panel items within it. As you say, property nodes of individual controls can be used although it's only a matter of time before people start asking for it - so I was thinking why not make it available at the outset? And I was really only thinking of properties which are very common, such as visibilie, disabled etc.

I marked item 6 as optional because it's not the main reason for the idea which was productivity improvement in designing and modifying front panels so I agree with you that it may be less important.

I can imagine that there might be much debate over that part so would rather have layers available for front panel design only than not have it because programmatic control was undesirable or too hard to implement.

I like your idea of alignment between objects on different layers - that might be accomplished by clicking on layers (ctrl-clicking for example) and then dragging around a collection of front panel objects and then aligning / distributing using the existing tools.

@Peti: I use tabs that way too but I think layers offer something that tabs can't, especially as Manzolli says, not being restricted to a rectangular area.

[Manzolli]

Even though layer may be based also in rectangles, complex shapes can be created composing many small rectangles.

[magicbean]

@Manzolli: As layers have no visible structure and no bounds in X and Y (they only have a top to bottom order), the front panel objects can go anywhere you can place them on the front panel - just like with the current version of LabVIEW. The difference is that they are now also attached to a layer which may end up having programmable attributes.

Therefore no need to create shapes with layers.

[Manzolli]

@magicbean: The programmer will need a visual help to visualize which object belongs to which layer. I was thinking in rectangles, but you are right, since the layers are not visible. NI could implement something similar to the Disabled Structure where the disabled elements are faded.

[Intaris]

While I am not against this idea, I feel the changes needed for LVs drawing engine need to go much further to get it close to being a modern implementation.  Things like missing transparency, custom overlays, performance hit from overlaying controls and so on are all testament to the age of LV.  While a lot may have been tweaked over time, I feel at some stage a more radical and far-reaching change is required.

But since THAT idea won't get traction, I'll vote for this.

[Todd_Lesher]

There are useful comments on z-order here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Programmatic-Manipulation-of-Object-Layer-z-order/idi-...

and here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/layer-manager-layer-property/idi-p/1078154

The definition of layers in this idea feels like a side-view of the z-order: a property node that acts on all controls that are in the same z-state.