GNOME Bugzilla – Bug 766883
mouse scroll wheel to pan workspaces with multiple monitors
Last modified: 2016-09-27 00:04:22 UTC
I have 2 monitors and make use of at least 3 workspaces at the same time. The problem I am having is when I go to Overview and I use the scroll wheel, it works fine as long as I am either scrolling over the primary monitor, or over an application on the secondary monitor. Along with this, the scroll wheel works fine almost anywhere on the primary, but the mouse has to be DIRECTLY over an application on the secondary. Proper function would be to have the same behavior for all monitors. As right now I try to scroll past 2 or 3 workspaces, but get stuck on one when my secondary monitor is empty.
Created attachment 328569 [details] [review] overview: Pass on scroll-events on background group as well The Overview::scroll-event is meant to expose scroll events that happen anywhere in the overview, but for now only work on the primary monitor. Include events on the background group that is known to span all outputs to fix.
Created attachment 328570 [details] [review] workspacesView: Consider workspaces-only-on-primary when scrolling It is odd to switch workspaces using the scroll wheel when the pointer is on a monitor without workspaces, so only handle scroll events on non-primary monitors when workspaces-only-on-primary is disabled.
Review of attachment 328569 [details] [review]: Do we still need to handle scroll events in this._controls.actor ?
Review of attachment 328570 [details] [review]: ok
Review of attachment 328569 [details] [review]: In fact, since the scroll events handler propagates the event don't we get duplicate scroll signal emissions this way?
(In reply to Rui Matos from comment #5) > In fact, since the scroll events handler propagates the event don't we get > duplicate scroll signal emissions this way? No, though I have to admit that I can't figure out off-hand what is stopping the event ...
(In reply to Florian Müllner from comment #6) > (In reply to Rui Matos from comment #5) > > In fact, since the scroll events handler propagates the event don't we get > > duplicate scroll signal emissions this way? > > No, though I have to admit that I can't figure out off-hand what is stopping > the event ... I finally had some time to revisit this - updated patches coming.
Created attachment 330326 [details] [review] workspacesDisplay: Cancel click when panning When switching between workspaces via panning, we don't want to leave the overview when we end up on an empty workspace. Drive-by fix.
Created attachment 330327 [details] [review] overview: Remove stack actor The stack was used to overlay a message indicator over the overview group. That indicator is long gone, so there's no longer a need for an intermediate actor in the hierarchy. Another drive-by fix.
Created attachment 330329 [details] [review] overview: Move overview actions and scrolling to background group Both the Overview::scroll-event and actions added via addAction() are meant to work anywhere in the overview, but for now only work on the primary monitor. Move the handling to the background group that is known to span all outputs to fix.
Created attachment 330332 [details] [review] workspacesView: Allow activating empty workspaces on any monitor We allow activating a workspace by clicking it when we know that the user did not try to select a window and missed (namely: the workspace is empty). However we currently always check for an empty workspace on the primary monitor, which doesn't make sense when the click happened on a different monitor.
Created attachment 330334 [details] [review] workspacesView: Consider workspaces-only-on-primary when scrolling It is odd to switch workspaces using the scroll wheel when the pointer is on a monitor without workspaces, so only handle scroll events on non-primary monitors when workspaces-only-on-primary is disabled.
Created attachment 330335 [details] [review] workspacesView: Consider workspaces-only-on-primary when panning It is odd to switch workspaces on the primary monitor when panning on a monitor without workspaces, so reject the gesture on non-primary monitors when workspaces-only-on-primary is disabled.
Review of attachment 330326 [details] [review]: This didn't seem to be a problem for me and we already do it on ::gesture-end but it doesn't hurt either
Review of attachment 330327 [details] [review]: ok
Review of attachment 330329 [details] [review]: looks good
Review of attachment 330332 [details] [review]: fine
Review of attachment 330334 [details] [review]: indeed
Review of attachment 330335 [details] [review]: ++
Created attachment 330407 [details] [review] workspacesView: Initialize the adjustment's upper bound Initializing the upper bound to zero means that on panning we'd start scrolling from the first workspace even if the current workspace when entering the overview was different since StAdjustment clamps the value to be inside bounds. -- noticed while testing your patches
Review of attachment 330407 [details] [review]: LGTM
(In reply to Rui Matos from comment #14) > Review of attachment 330326 [details] [review] [review]: > > This didn't seem to be a problem for me I'm definitively seeing this using a touchpad. > and we already do it on ::gesture-end but it doesn't hurt either Mmmh, I missed that. We don't do the same on ::gesture-cancel though, which fixes the issue for me as well. Moving the call there is more consistent, so I'll do that.
Comment on attachment 330407 [details] [review] workspacesView: Initialize the adjustment's upper bound Attachment 330407 [details] pushed as 500ea13 - workspacesView: Initialize the adjustment's upper bound
Attachment 330326 [details] pushed as 02bad8e - workspacesDisplay: Cancel click when panning Attachment 330327 [details] pushed as 5182129 - overview: Remove stack actor Attachment 330329 [details] pushed as c39ffa1 - overview: Move overview actions and scrolling to background group Attachment 330332 [details] pushed as e16f63a - workspacesView: Allow activating empty workspaces on any monitor Attachment 330334 [details] pushed as 2ad2853 - workspacesView: Consider workspaces-only-on-primary when scrolling Attachment 330335 [details] pushed as 21ddbf0 - workspacesView: Consider workspaces-only-on-primary when panning
*** Bug 694835 has been marked as a duplicate of this bug. ***