I know there is alt+mouse wheel zoom feature in xfwm4 but: 1. you won't find such a feature called zoom in the settings. 2. in order to assing a different key for zooming, for some reason, you have to pick one from "Key used to grab and move windows" which has nothing to do with the zoom definition. 3. probably this one is the most important one, there is no configuration settings for the zoom option. Zoom works only in sync mode, it means that whenever you zoom in an area on the screen, the zoomed area follows the mouse move, which is annoying, distracts you from reading whatever article you read and it's just hard on eyes to watch the zoomed area moving, jumping fast backward, forward, up and down together with the mouse move. for the first two issues, I'd suggest to include a separate zoom settings in the accessibility tab, so it is clear that it's about zoom and has nothing to do with windows moves and other unrelated stuff, for the 3rd issue, I'd suggest to include two zooming modes (ala compiz): 1. sync mode - which is the current one 2. pan area - wich will keep the zooming area while moving the mouse aroand and will only move the zoomed area whenever the mouse arrow reaches on of it's borders, In my opinion, zoom is a super important feature for any desktop, because there are people with weak sight and it's difficult to have a productive work without a good zooming feature. Thank you!
Regarding this issue's title: there's already a patch for exposing the zoom_desktop xfconf setting: https://bugzilla.xfce.org/show_bug.cgi?id=11121 However, the other points are also good proposals. So maybe this bug should be renamed "desktop zoom enhancements". Another proposal: integrating https://en.wikipedia.org/wiki/Pixel-art_scaling_algorithms .. I've noticed recent versions of the windows magnifier tool have this nice usability enhancement. For implementation, maybe this could be of use: https://github.com/libretro/common-shaders
Panning isn't possible because we don't have cursor redirection in xfwm.
So in more detail: If you click the mouse while zoomed in, X11 doesn't know, so it sends the event to the x, y position of the mouse pointer as if there were no zoom. Because of this we have to manipulate the zoomed in texture in such a way that the pointer always appears to be over the same pixel regardless of zoom level. It just happens that this also allows you to pan around. But it means we can't change how the panning works because then click events would go to the wrong windows/buttons etc. To fix that we would need to grab the pointer and remap the event locations according to the zoom/pan parameters. This is a fairly large amount of work compared to the relative simplicity of the current implementation.
Thx for the explanation Alistair.. I actually find the current panning implementation quite well usable once you get accustomed to it.. Maybe wayland will allow for a different approach here. Still looking forward to be able to *rotate* my windows 🤣
@2: "Grab window" = "Desktop Zoom" I have the same problem. Apparently both functionalities use the same hotkey-information. Suggestion1 (quick fix): Add something like "(This is also the hotkey for desktop zoom with mousewheel)" below. Suggestion2 (real fix): Change to logic, so to not use the same hotkey information.
Could be done with XTEST to insert new mouse events, or could be done by xrandr panning in conjunction with the xfwm4 composited zoom so the existing event hits the right virtual pixel after xrandr remaps it. I admit that would not be child's play to implement. Digressing (some may be interested in this as a workaround for the time being): On intel display hardware with xrandr 1.4+ it's possible to do the zooming and panning entirely in xrandr - no need to enable compositing or use the GPU for scaling. ie xrandr --output LVDS1 --mode 1920x1080@60 --scale 1.5x1.5 --panning 1920x1080 results in a zoomed area that can be pushed around with the mouse. It's also possible to set up a proportional scroll like xfwm4's default 'sync' behaviour, and a sort-of hybrid of the two with a certain size dead area in the middle... see man xrandr for more info. (In reply to Alistair Buxton from comment #3) > So in more detail: If you click the mouse while zoomed in, X11 doesn't know, > so it sends the event to the x, y position of the mouse pointer as if there > were no zoom. Because of this we have to manipulate the zoomed in texture in > such a way that the pointer always appears to be over the same pixel > regardless of zoom level. It just happens that this also allows you to pan > around. But it means we can't change how the panning works because then > click events would go to the wrong windows/buttons etc. To fix that we would > need to grab the pointer and remap the event locations according to the > zoom/pan parameters. This is a fairly large amount of work compared to the > relative simplicity of the current implementation.
I came looking to add to an existing bug I expected to see reported by parityerror in xfce forum https://forum.xfce.org/viewtopic.php?pid=52639#p52639 There's a bug in xfwm4 in that the screen zoom is leaking modifier+zoom events to the window under the cursor when desktop zoom is enabled. This has various destructive / non-destructive artefacts depending on the application window the mouse happens to be over. Please clear handled events from the queue, since this has adverse effect on accessibility usage of this feature!
It would be nice to make desktop zoom work when modal / droplist / dialog boxes are open. For example, click the xfce menu icon and then try to zoom while it's open. Or click a droplist in Firefox and while the droplist is open, try to zoom to read the entries after discovering the font is too small/fine/low-contrast. These are serious papercuts for people with visual impairments.
I think the setting could be at window-manager-tweaks > Compositor > screen zoom feature so that all settings related to Compositor could be found in one place.
I need the grab option, but I would like to be able to disable the zoom thing even if I use compositor. Or even better, have a different modifier key for that, or maybe a pure keybinding. Background: I have a common Logitech K400 keyboard+pointer device and the pointer device is eager sending kinetic scrolling events. If I press the modifier key e.g. to switch window while it is doing the kinetic scrolling, it has unexpected zooming effect. What are all those Hyper, Meta and Mod keys anyway?
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/276. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev