Feature request - Frame specific zoom about muximux

[evanmj]

Zoom buttons would be excellent if there is a decent way to add that at the css level or using viewport settings or what have you. +1 for this feature req :)

[mescon]

I'll see what I can cook up. Do you think the zoom should be a setting on the settings view?

[evanmj]

I would think either a hotkey or (if enabled) a tiny plus and minus icon on each side of the tab maybe? Theoretically having it remember the setting would let you add it to the settings of the item, which would be good enough. In essence you'd be setting zoom for each tab relative to "no zoom", so 0.9 or 1.1, etc.

[mescon]

Well, doing it in a hotkey would basically make it into the same thing the browser already does, so I don't exactly see the point of it... or am I missing something?

[evanmj]

The browser hotkey (Ctrl + and Ctrl -) zooms the entire dash, making the tabs themselves get larger and smaller as well as the content within them. Breaking that functionality would be bad, but I'm thinking maybe ctrl-alt + (if possible to bind to that) would zoom only that tab. I imagine you could do that with a bit of css or with the viewport setting (sorry, I don't have much web dev experience).

Even just having a new field on the 'setting block' for each tab that the user could put in a % zoom would be great to sort of 'normalize' the views. I run zoneminder on mine and (due to problems with the zoneminder UI), the console needs zoomed way in, but the live video feeds need zoomed way out, so with different tabs with individual zoom factors I could have it all just right.

Hopefully that clears up my comments.

[mescon]

There is still a bug in webkit-browsers whereby the viewport size extends further than the actual contents of the iframe, causing a scrollbar - though only when the scale is less than 100%. I have yet to able to work out exactly what the problem is.

[mescon]

Would somebody be willing to switch to the develop branch and test this out?
Perhaps if any of you have any ideas for how to fix the bug in webkit-browsers?

[mescon]

Nevermind - found the problem and fixed it. Pushed to develop branch.
I'll close this issue now, as this is currently live in develop which will be merged to master when a couple of more things has been fixed.

[evanmj]

Thanks, I'll try to test it tonight.

[evanmj]

Pulled e6dad15 from Develop and tested just now.

All zooms defaulted to 10% in the settings menu and the settings.ini.php file (should probably be 1.0, not 0.1).

After saving and reloading from the settings gui, the settings.ini.php file is updated, however the next time you open the settings gui, it defaults all settings back to 10%. (It seems like it is not pulling this data from the file properly and displaying on the settings page).

I did get everything working by manually typing in the zoom percentages in the settings.ini.php manually, and it works really well.

[evanmj]

Disregard last comment. Here is a better description of the problem:

When upgrading, scale in the settings.ini.php file defaults to 0.1, it should default to 1.0.

I tried adding an item in settings, but the zoom section did not show up on new tabs, just ones that already existed. Once a tab is created and then you go back into settings it shows the zoom level.

One other thing to consider, maybe i++ should be i+=5... I think 5% increments should due just fine and make for less scrolling to select the zoom level. If a user needs 37% (for instance instead of 35%) they could simply edit the settings file manually.

[mescon]

Blast!
I was unsure how this would handle... I'll try and rewrite some stuff and see if I can get it fixed.
It's losely tied together with our efforts to remove legacy code for parsing the settings file and instead use Config_Lite.

When I've made some progress on this I'll let you know and see if you could test it out for me.

[mescon]

Fixed this.