! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Compositor zoom makes the screen follow the cursor without an opt-out
Status:
RESOLVED: WONTFIX

Comments

Description ehymail 2015-03-16 12:52:59 CET
As I have zoomed in with the xfwm4 compositor, the screen now follows the mouse as I move it around. This makes zoom function unusable for gaming and work when I need to have screen position locked like it would have without zoom.

I would hereby like to request an option to disable all screen movement under zoom while still being able to move the mouse cursor normally.
Comment 1 Olivier Fourdan editbugs 2015-03-16 12:59:58 CET
This is not the intended use of zooming. zooming is intended primarily as an accessibility feature.

Because the area is larger when zoomed, the area must follow the pointer. MAking this optional makes no sense at all.

If what you need is a smaller resolution, then change the resolution (even temprorarily), use xrandr or xfce4-display-settings for that.
Comment 2 ehymail 2015-03-16 13:23:42 CET
I appreciate quick answer, but I'm also very surprised and disappointed that this was also downright rejected instantly. Would you need funding for this to happen? This is very important.  Why is it not intended way of zooming? And could you elaborate why it being optional does not make sense? I thought xfce was about freedom of choice.

Temporal smaller resolution steps with mousewheel through xandr or displaysettings are not quite accessible (not sure if at all) and it would be slower process and it would break content that was in the higher resolution (screen recorder for example).

If this is impossible feat for xfce, would you even consider option for screen that it moves only after it touches the borders of the screen?
Comment 3 Olivier Fourdan editbugs 2015-03-16 13:32:26 CET
I really do not want to add an option for anything and everything.

This is counter productive, it costs, but not money, it costs time, adds complexity to the code, make it more fragile less enjoyable to work on, leads to bloated code, etc.

It is already impossible to test all the combinations of existing options, I don't want to add more unless it really makes sense - And here it does not make sense).

So my answer is no, reopening the bug won't help. Funding neither, I fancy my freedom , money can't buy it.
Comment 4 ehymail 2015-03-16 15:00:22 CET
You say it doesn't make sense. Do you think Mozilla is senseless when their program zooms web pages without Firefox forcing the screen to constantly move along with the cursor?

If you really think about it for a moment, it makes less sense to have the screen always move with the cursor, because it limits the usage tremendously (like you cannot click something and then see whats happening on other side of the screen because it's no longer there).

I can't imagine it being hard to implement. All that I'm asking for is a command or a value in configuration file to stop the screen movement.

Please!
Comment 5 Olivier Fourdan editbugs 2015-03-16 15:36:47 CET
(In reply to ehymail from comment #4)
> You say it doesn't make sense. Do you think Mozilla is senseless when their
> program zooms web pages without Firefox forcing the screen to constantly
> move along with the cursor?

That's entirely different , FF implements zooming by re-rendering the page, it basically change the size of the fonts and the size of the images, and re-render the web page.

> If you really think about it for a moment, it makes less sense to have the
> screen always move with the cursor, because it limits the usage tremendously
> (like you cannot click something and then see whats happening on other side
> of the screen because it's no longer there).

If you think about, you'll realize what you ask is technically very complex.

What is zoomed is the screen *content*, the input device (ie your mouse) remains the same, its coordinates remain the same, so of you don't follow the cursor, the actual event won't match the location of the cursor, and it will be impossible to click anywhere.

> I can't imagine it being hard to implement. All that I'm asking for is a
> command or a value in configuration file to stop the screen movement.

This is really not so simple, the input remain the same, it's the content which is zoomed, therefore there is no other possibility (*) than keeping the zoomed area in sync with the pointer position.

--
(*) there could be one possibility, using input device transformation matrices (assuming it works with relative input devices such as mice, which I am not sure), but I reckon that falls completely out of the role of a window manager to change device input matrices on the fly.
Comment 6 ehymail 2015-03-16 17:08:42 CET
Ok thanks for explaining and bearing with me.
I have found that compiz has sense on this one because their ezoom can do the thing which I'm requesting so it shouldn't fall "completely out of the role of a window manager".

Compiz toggle zoom area lock:
"When locked, the zoom area (field of view) will not move to follow the mouse cursor. <Super>l"

I have not tried compiz yet, mainly because I'm hesitating if it brings other problems to my system. Things are currently very fine for me except for this one thing. 

I really love xfce and xwfm, but if this feature (crucial one to me) can't be added I have no choice but to look at the alternatives.

Thank you for your time.
Comment 7 Olivier Fourdan editbugs 2015-06-01 09:08:15 CEST
*** Bug 11951 has been marked as a duplicate of this bug. ***
Comment 8 Vanessa Dannenberg 2015-06-01 15:46:44 CEST
Quite frankly, rejecting this idea out-of-hand is a bad response.

The always-panning makes this feature equally unusable for accessibility purposes.  Users need to see as much as possible, which means centering the viewport on the most important parts of the display.  This is impossible with the current behavior.

Please reconsider adding this feature.
Comment 9 Olivier Fourdan editbugs 2015-06-01 15:55:31 CEST
(In reply to Vanessa Ezekowitz from comment #8)
> Quite frankly, rejecting this idea out-of-hand is a bad response.
> 
[...]
> 
> Please reconsider adding this feature.

Please read again my reply in comment 11938, I am not rejecting this feature, I am saying it is not possible. But you don't have to believe me, just send me patches and prove me I'm wrong.
Comment 10 Olivier Fourdan editbugs 2015-06-01 15:59:14 CEST
(In reply to Olivier Fourdan from comment #9)
> (In reply to Vanessa Ezekowitz from comment #8)
> > Quite frankly, rejecting this idea out-of-hand is a bad response.
> > 
> [...]
> > 
> > Please reconsider adding this feature.
> 
> Please read again my reply in comment 11938, I am not rejecting this
> feature, I am saying it is not possible. But you don't have to believe me,
> just send me patches and prove me I'm wrong.

Sorry, I meant bug #11951#c1 of course. where I explain why this is not possible.
Comment 11 Olivier Fourdan editbugs 2015-06-01 17:31:04 CEST
(In reply to Olivier Fourdan from comment #10)
> Sorry, I meant bug #11951#c1 of course. where I explain why this is not
> possible.

Well, actually, thinking about it, I guess this is possible after all, by decorrelating the actual cursor position from its representation on screen.

Basically, as we now draw the cursor while zooming, nothing forces us to draw it where it actually is, so we don't really have to move the image to match the position... for the apps and events what matters is the real position.

Patch, anyone? I reckon it would make the code fairly more complex.
Comment 12 Vanessa Dannenberg 2015-06-01 17:45:10 CEST
It's always been my contention that virtually anything is possible with enough effort. While I'm not a C/C++ programmer and can't make such a patch, you might get more bites if you remove the "resolved, wontfix" status of this issue. :-)
Comment 13 Olivier Fourdan editbugs 2015-06-02 14:01:13 CEST
(In reply to Vanessa Ezekowitz from comment #12)
> It's always been my contention that virtually anything is possible with
> enough effort. While I'm not a C/C++ programmer and can't make such a patch,
> you might get more bites if you remove the "resolved, wontfix" status of
> this issue. :-)

It would still won't work with direct pointing devices such as touchscreens, whereas the current implementation is guaranteed to be correct in all cases.
Comment 14 freaking.weasel 2015-07-05 18:22:47 CEST
I'm highly interested in this as well,  just to zoom in on some applications with fixed-sized windows. Of course needless to say I need it to NOT follow the mouse pointer. I was told to create an enhancement bug request on the forum, but I found this one so I'm posting here instead. (from https://forum.xfce.org/viewtopic.php?pid=38011#p38011)

Please, make it not follow the mouse. Why is locking so hard to implement? I mean just store a variable that says how much you zoomed in (zoom factor) and then the pan position on the screen? The mouse coordinates should just be absolute always, as if looking at the whole screen, and the zoom just "restricts" it to that area (based on pan/zoom factor).

By the way, I *may* take a look at the source code even though I'm bad at technical stuff, but, give me some hints of where to look first (i.e where is it in what file and what would have to be changed). But probably if it's hard to implement, then I guess I will have no chance to do it.

If Compiz has a "lock screen" when zooming option, then can't you just look how they done it and copy?

Anyway, please reconsider adding this option, I can't stress it enough how much some people need it.

We wouldn't be asking if it was possible in some other way, but it's not even with 3rd party applications, they all follow the mouse (without changing window managers, if compiz can).

Thanks for possibly reconsidering this.
Comment 15 freaking.weasel 2015-07-05 18:28:54 CEST
Oops sorry that links to my last post, please read the opening post for the description (I posted it yesterday when I was in bad mood, please don't mind my tone... I just wasted too much time looking for this in other software, I was too frustrated).

On the other hand the Status of this bug is misleading, please change it to something more adequate (even if you won't fix it anytime soon at least someone else might try at it?)
Comment 16 Olivier Fourdan editbugs 2015-07-06 09:41:33 CEST
(In reply to freaking.weasel from comment #15)
> On the other hand the Status of this bug is misleading, please change it to
> something more adequate (even if you won't fix it anytime soon at least
> someone else might try at it?)

I am quite opposed to the idea of adding a lot of complexity for what I still consider a corner, so as far as I am concerned, it's still a wontfix.

Now if someone wants to prove me wrong and bring a simple patch (e.g. based on my comment 11) that works with all types of input (direct and indirect), then I won't stop him/her from trying, but that won't be me (and I give no guarantee that I would merge it either).

Stating that everything is possible as in comment 12 is pretty useless and won't help anyone though. We are small team with very limited resources, so I'd rather stick to the principles that led xfce for the past 20 years or so, i.e. keep things simple so I can maintain it and still enjoy it. Selfish? certainly, but I'm fine with that.

Bug #11711

Reported by:
ehymail
Reported on: 2015-03-16
Last modified on: 2015-07-06
Duplicates (1):

People

Assignee:
Olivier Fourdan
CC List:
2 users

Version

Version:
4.12.0

Attachments

Additional information