request: ButtonGrid view quick change on GUI button click

[tcconway]

Is this a feature relevant to companion itself, and not a module?

• I believe this to be a feature for companion, not a module

Is there an existing issue for this?

• I have searched the existing issues

Describe the feature

Create three new interface buttons in the Buttons Editor tab, to dynamically adjust the visible button grid in the editor for different device layouts. This feature will enhance usability by allowing users to preview and work with specific configurations for devices like Stream Deck, Stream Deck +, and Stream Deck XL without having to go into Settings.

In different scenarios, I use StreamDeck XL along with StreamDeck+ (and even ScreenDeck software). Sometimes I forget which hardware I'm building pages for and sometimes create buttons that are outside the grid of the specific device.

Proposed Implementation

Button Edit page
Add three new interface buttons to the Buttons tab, each representing a pre-configured grid layout. These buttons will allow users to switch the visible rows and columns in the editor, providing a tailored view for specific devices.
View 1:
• Default Layout: 5 columns x 3 rows (Stream Deck Standard)
• Purpose: Tailored for users working with the original Stream Deck.
View 2:
• Default Layout: 4 columns x 4 rows (Stream Deck +)
• Purpose: Matches the layout of the Stream Deck + for consistency.
View 3:
• Default Layout: 8 columns x 4 rows (Stream Deck XL)
• Purpose: Optimized for the larger XL version.

To simplify the GUI, this could be a single popup button allowing the user to choose which defined layout they'd like to see.

Customization Options
Update the Button Grid area in Settings that allows the user to setup the three view presets
• For each preset, the user can choose a Name for the preset as well as # of columns and rows
• Include a Reset button to reset all the preset names, columns and rows to "factory default" which would cover the three most popular StreamDeck sizes

This feature would provide a significant quality-of-life improvement for users managing multiple devices or complex button layouts, making the editor more intuitive and efficient. It aligns with Bitfocus Companion’s goal of delivering professional-grade tools for streamlining workflows.

Here's a down-and-dirty mockup, but this should realistically be just a single button with a popup .

Usecases

A user working with both a Stream Deck and a Stream Deck XL can quickly toggle between the “5x3” and “8x4” layouts to adjust and preview their button assignments for each device. This eliminates the need to scroll through unnecessary buttons in the editor, streamlining the design process.

Functionality
• Dynamic Grid Adjustment: Clicking one of the buttons updates the visible button grid in the editor to match the selected configuration.
• Non-Destructive Changes: Buttons outside the visible grid remain assigned and functional but are temporarily hidden from view.
• Seamless Switching: Users can toggle between layouts effortlessly, simulating how buttons will appear on different devices.

Benefits
1. Improved Workflow: Simplifies the process of designing and testing button layouts for multiple devices.
2. Enhanced Clarity: Reduces visual clutter by showing only the desired grid.
3. Customizability: Supports unique setups and allows for adjustments as needed.
4. Future-Ready: Easily extendable to accommodate new devices or layouts.

[Julusian]

It sounds like #2945 would solve what you are asking for.
That PR was put on hold over a discussion over whether it was a worthwhile feature, and didn't get picked up again, but I suppose this is motivation that such a feature is wanted

[tcconway]

Thanks for the reply. Lots of great thinking in #2945.

Personally, this is a VERY worthwhile feature. I can't tell you how many times I've created a button to realize later that I can't see it on the hardware.

+1 for having each page remember each view too.

[istnv]

I frequently use the surface offset with multiple devices on the same page.
The 8x4 XL grid also fits a 5x3 streamdeck + 3x2 mini side by side.
This allows more buttons on a page and fewer pages to track.
Off-surface buttons can have text 'notes' for page or hold special actions triggered from the Admin interface or web surface.

[dnmeid]

Well, again that boils down to the problem of users misunderstanding the programming UI with a simulator. I can understand the request for a WYSIWIG approach, but as I've already written in #2945 I think there are better ways of visualizing the real world setup. Especially ways that give a hint of your surfaces but don't limit you to a surface during programming. In contrary to the Elgato software Companion tries to be more open and especially suited to the use of multiple and different surfaces. As we have seen in the past users tend to work with changing hardware setups because e.g. they buy a new device, their old device breaks, they buy a bigger device, they add a device with encoders, they work for a company where device availability is not always guaranteed....
So imagine you have to redesign a layout e.g. to 5x3. If you are using the 5x3 view you can't reach some of the buttons, if you are using an unrestricted or larger view nothing is gained.
I still think it would be better to not limit the programming grid but instead give a visual hint where the surfaces are on the grid.

[tcconway]

better to not limit the programming grid but instead give a visual hint where the surfaces are on the grid.

That would be immensely helpful. Something as simple as a red bounding box (background color, or something) around a section of the grid would help so much. You’ll be able to work in the displayed grid but also see the confines of the hardware!

[Julusian]

I still think that we are trying to solve two separate use cases/flows here.
One of seeing the bigger picture, and one of focusing on a particular surface.

An XL would not be hard to figure out positioning from a simple outline, but that is not the case for something like https://www.blackmagicdesign.com/products/atemconstellation/techspecs/W-ABP-11. Trying to pick the correct button in the middle of that requires some trial and error. No outline will help with that.

I am still not keen on the view of https://user-images.githubusercontent.com/8548888/226913544-b9b2eca2-72e0-4cb7-b85d-97325d3c3dc7.png . I still think that is really hard to interpret and will never be able to give an accurate representation of what it will look like on the actual surface.
I have 5 different types/alignments of surfaces attached to my companion, all overlapping but on different pages. So unless that view has some configuration to select which pages to show each surface on it will not be any help to me

But I am warming to the idea of being able to outline arbitrary regions in the grid. These would be user defined, and would need to be configurable as to what pages each is shown on to avoid introducing too much noise. Perhaps this could be the basis of the 'bookmarks' that can be used to help move surfaces around the grid with actions. Each surface should probably mark one of these regions by default (with a way to turn it off/change the pages it shows on)

[dnmeid]

I still think that we are trying to solve two separate use cases/flows here.

Yea, most probably. I'm all in for having simulator views for the surfaces that show the surface in a way where you can affirm your programming, more or less can guess where the control is on the grid and can operate the controls. I'm also not opposed if there is a key combination or something where you can edit the control instead of operating it from the simulator. I can also imagine that a simulator view has additional page selection possibilities to help using it for programming. Maybe later we can offer something like a environment where you can arrange a few simulators like you have in real world and then users who want to work with that style can do it.

On the other hand I'd intentionally try to make the programming grid as generic as possible and not go in the direction of a more realistic representation of a surface in the grid. This may seem very tempting for single surface workflows or even for setups with multiple equal surfaces, but it would really give the mindset of programming this particular button and not some reusable control position.
For the purpose of styling your controls it would maybe be more useful to have selectable or multiple control previews in the button editor. Then you can see at once how your control will look like on different surfaces. We simply can't and shouldn't show multiple visualisations in one grid cell and I'm also not a big fan of having mixed visualisations in the cells (some square and some SDS format and some in all the other formats the future brings). I could warm for a customizable grid aspect ratio, so users with mainly one device type can tweak the grid to fit their devices best. But there has to be some other stuff first, like rendering per surface.

I am still not keen on the view of https://user-images.githubuse...

The intention of this was again something else. The purpose was having a graphical way of placing the surfaces, i.e. setting up the offset.
The solution of #2387 for the problem of this request would be the surface overlay in the grid view like this: https://user-images.githubusercontent.com/8548888/226913589-308e97be-6537-4a0b-b301-d6f518c20bc0.png (remember it is still only a mockup)
This would not try to give you a realistic representation how your surface will look or how a particular control will look, but where is a control located.
I tend to interpret the grid as a control selector.

Perhaps this could be the basis of the 'bookmarks' that can be used to help move surfaces around the grid with actions. Each surface should probably mark one of these regions by default (with a way to turn it off/change the pages it shows on)

My intention was never to move surfaces with actions. Whenever this has been requested I tried to refer to the windows system. I think windows are way more powerful, because you can combine and stack multiple windows. I think in Buttons they did a light version of the windows called regions and this seems to be a popular feature.
And having windows and programatically moving surfaces seems not necessary and overkill to me.
The bookmarks in #2387 are just an alternative way of adressing a location (this request is becoming more popular since reorderable pages arrived).

Should we go for this request with: (optionally) show some simple outline of the surfaces in the grid?
And discuss the more simulator / surface centric programming topics in #2945
And discuss the more evolution of the grid in #2387 or a new topic