RFC: full-screen zoom (accessibility via ctrl-scroll)

[ybakos]

Thank you for all things sway. I know there are way more important items, especially for 1.0, but I am submitting a feature request for accessibility.

On MacOS, a "killer" accessibility feature is enabling the user to zoom the entire screen via ctrl + two-finger scroll. While there are utilities for creating "magnifying glass" surfaces that zoom in on small parts of the screen, not many window managers support this like MacOS Quartz Compositor.

It would be amazing, and a big win for folks with accessibility needs, if this were a feature in Sway.

I myself don't have the chops to implement this and submit a PR. 😭

[ddevault]

This is something I'd like to see in sway, too. However,

I myself don't have the chops to implement this and submit a PR. 

This is nonsense, anyone can learn and many people have cut their teeth on sway.

https://drewdevault.com/2017/01/06/Actually-you-CAN-do-it.html

[ybakos]

@SirCmpwn I’m glad you’re a fan of the feature. I also did not mean to sound defeatist, and I do agree about the learning. Perhaps I should have said, “I have too much crap going on to commit to this.” Which isn’t an excuse either. 🤪

[Tormen]

👍 for a screen zoom feature. This is so handy. These days lots of software comes with their own zoom... but still I was using that 1 every day or 2nd-day under KDE and under compiz before that :)

@ddevault : As this feature seems to exist in wayfire, could you have a timeboxed look if there could be any chance to re-use / port this to swaywm or better to wlroots if that's possible ?

[ddevault]

No, it wouldn't be possible to port from wayfire to wlroots.

[ibotty]

Can you give a (very broad) overview on how to tackle this issue for someone not familiar with wayland and wlroots APIs?

[vidister]

@nkreer and I would like to implement this as well. But we're both not familiar with wayland/wlroots and need some hints on how to do start this.

[RazvanRotari]

I had a try to implement this by calling glViewport with a rect bigger that the screen, mostly worked ,but each app is zoomed independently, not the whole screen.

Another way of doing this might be to render the whole screen to a texture and then enlarge that one.

[myisaak]

Read the docs guys (@vidister hope this helps)!
wayland_client: https://wayland.freedesktop.org/docs/html/apb.html
wlroots: /~https://github.com/swaywm/wlroots/tree/master/protocol

[paolomainardi]

Any updates on this one ?

[frigaut]

Wayfire probably does that through OPENGL, which, unless I am mistaken, sway doesn't use. So I don't think implementation would be trivial. And it's a good thing that sway doesn't use OPENGL - saves your battery.

[emersion]

Sway does use OpenGL (it can also use Pixman on devices without a GPU).

[paolomainardi]

@emersion how much do you think is complex to build this feature on the current Sway codebase ? Assuming that all the needed pieces are still in place.

[paolomainardi]

It does!’t look like rocket science so far: /~https://github.com/WayfireWM/wayfire/blob/224bb669836ce987a7e17fe53291bb87a7b0140d/plugins/single_plugins/zoom.cpp

[frigaut]

Sway does use OpenGL (it can also use Pixman on devices without a GPU).

my bad

[Beryesa]

What about vulkan renderer

[teknico]

I had a try to implement this by calling glViewport with a rect bigger that the screen, mostly worked ,but each app is zoomed independently, not the whole screen.

Actually, zooming just one window is what I need. Is there a window manager that has this feature?

[tyalie]

I would also very much wish to see this feature come to sway. It would be awesome in order to explain to other people what you're doing right now.

[Simbi0z]

Is there a tool for wlroots based compositors that implements the magnifying glass feature?

[mooreye]

If anyone's interested, I hacked together a simple zoom in/out tool bound to a key. It zooms all outputs by a scale factor of ±0.1 either in or out. If scale is >=5, it will refuse to zoom in, and if it is <=0.25, it will refuse to zoom out, because overdoing it made my output glitchy and started killing windows. Change $mod+5 to your own key, and put this in ~/.config/sway/config:

# zoom in/out
bindsym --inhibited $mod+5       output * scale 1
bindsym --inhibited $mod+Shift+5 exec set -euo pipefail && scale=$(bc -l <<< $(swaymsg -t get_outputs | jq -r '.. | select(.focused?) | .scale')+.1) && [[ $(bc -l <<< "${scale} < 5"  ) == 1 ]] && swaymsg "output * scale ${scale}"
bindsym --inhibited $mod+Ctrl+5  exec set -euo pipefail && scale=$(bc -l <<< $(swaymsg -t get_outputs | jq -r '.. | select(.focused?) | .scale')-.1) && [[ $(bc -l <<< "${scale} > .25") == 1 ]] && swaymsg "output * scale ${scale}"

[vishalpaudel]

👀

any updates? the above command from @mooreye doesn't seem to work for me, pipefail doesn't seem like an option for me.

[mooreye]

👀

any updates? the above command from @mooreye doesn't seem to work for me, pipefail doesn't seem like an option for me.

I guess your sh command corresponds to a different shell than bash where there is no set -o pipefail option? In any case, try pasting these exec ... commands into a file with #!/bin/bash as the first line, make it executable, and put path to this file as a command.

[sertonix]

You can also remove o pipefail since it isn't used.

[bobblkabb]

bindte = CTRL SHIFT, mouse_down, exec, hyprctl keyword cursor:zoom_factor "$(hyprctl getoption cursor:zoom_factor | grep float | awk '{print $2 + 0.05}')"
bindte = CTRL SHIFT, mouse_up, exec, hyprctl keyword cursor:zoom_factor "$(hyprctl getoption cursor:zoom_factor | grep float | awk '{print $2 - 0.05}')"

[vishalpaudel]

ya, the command works using bash, but doesn't really do what I needed, a workaround I have is to

1. use grimshot save screen
2. open the saved image in fullscreen in firefox
3. zoom using the firefox image viewer

I could maybe do something like:

zoomfile=/tmp/zoomimage.png grimshot save screen $zoomfile | xargs firefox --new-tab

[telychko]

All of that approaches is a workaround. It should be implemented in compositor (of course if it's not against it's philosophy).

That's my workarounds:

SCALE="$(swaymsg -t get_outputs | jq ".[] | select(.focused == true) | .scale" | awk -vv="$1" '{print($1+v)}')"
swaymsg "output - scale $SCALE"

Where $1 above is the scale factor

[acidiclight]

I once upstreamed a change to KWin earlier this year to fix problems with its screen zoom functionality on multiple monitors. Currently, that means it's the only compositor so far that does zoom just as well as Windows or macOS do. I'm biased in saying this but I'd go so far as to say it should be the standard for all compositors to reference.

I'm not at all familiar with Sway, how it works, or how to work with its code. I'd be willing to learn, but I'm very VERY blind and that's going to be a challenge that involves other people. I'm a bit nervous as well because I did just have a really poor experience trying to get started implementing this in another compositor. But I'm sure that, with someone's help at least at first, I could handle implementing a zoom effect.

The main challenge with screen zoom is how you handle the mouse and how you handle multiple displays. A lot of compositors that do already have magnification, including Hyprland, only support proportional and tight mouse tracking. This means the zoom area directly moves with the mouse, either proportionally or keeping the mouse in the middle of the screen. This is simpler to implement but can be extremely nauseating at large zoom levels like what I need (3000%+, yes, thousand).

If I were to do it, I'd have to know how Sway handles monitor rendering and multi-screen arrangements, and how it renders the mouse cursor. In Kwin's case, monitors are rendered on a giant mosaic and the zoom code takes advantage of this.

[emersion]

Can you expand a bit on what the fancy zoom looks like and behaves? I'm not super familiar with accessibility and it's not super clear what makes KWin's zoom different from the naive approach. Is it just a matter of how much the zoomed viewport moves when the mouse moves?

It might be a challenge to implement in Sway right now because wlroots' scene-graph API doesn't support this. However, if the zoom isn't too fancy it shouldn't be too hard to wire up in wlroots. For instance wlroots could have a source rectangle property for each scene-graph output.

[ybakos]

On MacOS, the zoom feature has a few options for its behavior, but in general, here is how it works - or at least, how I use it.

1. Control + two-finger-scroll gesture to zoom in or out.
2. When zoomed in, moving the mouse cursor to the edges of the viewport/screen moves the zoomed viewport across the whole "desktop."

Zoom.Feature.mp4

[TTWNO]

There's also usually a setting to have the cursor stay centerwd when zoomed in, it only movea once your viewport ia blocked by the edge of tbe screen.