feat: add zoom control to grid view

[Julusian]

This needs some UX/design work, but is functional.

The idea is to allow you to scale/zoom the grid, either to make it easier to read/see the buttons, or to fill the available space fully.

TODO:

• Figure out how to make this look good
• Figure out where this should go in the import page, and add it there too

[krocheck]

I played a little locally, so I can commit if you'd like.

• Moved 'Home' button down, to separate page stuff from nav stuff
• Added padding to the bottom of the row
• Removed padding right of up/down buttons (not sold on that)
• Adding scaling to the placeholder text
• Scaling to 200% seemed excessive, so I changed the range to 50-150

I had a friend recommend a zoom presets dropdown, but I don't know that's necessary at the moment with steps being 10%.

[dnmeid]

From my experience with similar software, like media servers or CAD, I think zooming is a feature which should not take too much space on the UI. Especially a slider in my experience has proven to be quite useless. It usually is quite hard to slide to the desired zoom level and the indicator is quite small. So I would drop the slider at all.
The + and - buttons should have a magnifying glass icon with + and -, 10% steps should be ok.
The numeric entry field should be just large enough to fit a three digit number like the 150.
We should generally think of wether it would be better if larger numbers zoom in or zoom out. Naturally I'd say the larger number zooms in and the buttons are larger then, like a magnifying factor. But the problem with this is that we then limit the wide end. With a step width of 10% you conveniently stop at 10% which would show a maximum of ca. 80 buttons where 8 buttons are at 100%. This may seem to be many enough today and you won't be able to read the buttons at that size anyway, but I have the impression that with large configurations in the future we should not limit ourselves at the wide side.
So maybe we just reverse the meaning of the numbers to 100% is normal size and 150% shows you 50% more buttons, i.e. 12 buttons where there were previously 8. That way we would naturally limit the less useful tele end and can go very high at the wide end if needed. Then the + and - steps should be logarithmic.
Also from my expreience I think keyboard, mouse and touch control is very important for zooming, more important than buttons.
Zooming should be possible with keyboard CTRL+ and CTRL- regardles of focus (we have only one zoomable element). For keyboard zooming the anchor should be the selected control or the center of the grid view if no control is selected.
For mouse zooming I suggest the mouse wheel and the anchor is the position of the mouse pointer. Mouse zooming should work if the mouse pointer is over the grid view, even if the grid view doesn't have focus. I have seen often that zooming out a lot and then zooming in again to the desired area is an alternative way of navigation because you do not have to remember the direction to scroll to and are able to find the desired section faster.

[Julusian]

I don't think we should reverse the mensing of the numbers. I can't think if anything I have seen with that, so that would be very non intuitive to me.

Perhaps this should be on a little popup? Not a modal, but a little tool tip like panel that appears when clicking on a magnifying glass button. That way it won't feel like wasting space.
The button could have a label of simply the icon and the current zoom (like the others, dropping the value when on narrow screens)

I do think a slider is useful for quickly picking a size that you aren't sure what it will be. In other software which has just a dropdown, it's taken me some trial and error to find the correct zoom.

[dnmeid]

I like the popup idea.
Something like this:

I wouldn't mind the slider in a popup, I still don't consider it to be really useful but in a popup it doesn't harm much.

What would be your solution for the limit of the zoom range? For me another reason against the slider because sliders usually have a fixed range and if they don't have it is unintuitive again.
Maybe we don't use percentage as the value. What about using the number of buttons per view width? Then you can directly enter 8 and see 8 buttons fitting in the view.

[krocheck]

I prefer the slider functionality as implemented, with 10% steps. I did test and it was useful down to 20% once I added scaling of the placeholder text. I tested with a 64x64 grid. Now, Ctrl+ scrolling would be really cool, but I like the slider. Zoom to fit is a good idea.

I suppose setting a scale based on number of buttons wide isn't horrible, just noting that the size itself will be variable as the browser width changes. But that is how it used to work before the expandable grid. The popup/dropdown could work well.

[Julusian]

What would "Zoom to fit" do? Consider that the size of the grid could be close to infinite. It could fit any content, but again that could be 100s wide, and should it use the same scale for each page, or be based on the contents of only the visible page?

I'm not keen on the idea of scaling based on number of buttons. As someone who rarely maximises windows (doing so on a 32x9 gives silly results), the size of the window varies day by day. (I feel like this is also common on macos, as macos discourages maximising windows)
So I feel like I would get annoyed with this, as most of the time I want them at a sensible size, rather than wanting to see all of a certain area.
That said, I'm not opposed to there being some generated zoom options, such as 114% (8 buttons). Or both modes could be done, with a fixed/dynamic zoom toggle.

[dnmeid]

The screenshot I posted is from a different software and was only meant to be an example for the popup idea, not for the items of that popup.
I think "zoom to fit" is not something very clear in the context of Companion. If we want to have that functionality, I would call it "zoom to all" or "show all" and then, yes, it would show all used buttons of the current page. If it is 100s wide, then it actually makes the most sense. Zooming out to 100s of buttons is a very common thing to get an overview of all your buttons, to quickly find the button you are looking for and then you zoom in to the desired area to work there.

Personally I would consider it an advantage if the grid scales with the window. The usual way of working with windows is that you are most often using roughly the same size, wether it is maximised or not. You set up your window and then you set up how much you want to see in the grid view. If I now adjust the window size a tiny bit, I'd prefer that the grid view still shows the same cutout. If I adjust the window size a lot, I may have to readjust the grid view. So which one of the two ways is better, depends on wether we think the users will more often do large window size adjustments or more often small or no window size adjustments.

So I still vote for a solution where we not are limiting the wide zoom end. Ultimately supporting both ways could please anybody. In that case I'd suggest to have a smarter entry field. If you e.g. enter 130% (including %), you will end with a fixed scale of 130%. If you enter 16 (without %), you will end with 16 buttons scaling dynamically with the window. In the dropdown we can easily give a few presets for both methods. The entry field still can have the tiny arrows to increase/decrease whatever was entered, e.g. % by +/- 10% and buttons by +/- 4. Keyboard shortcuts could do the same. So we would not need two modes, where the user has to flip a switch, he just can use both variants.