GNOME Bugzilla – Bug 686639
mouse scroll wheel to pan workspaces instead of zooming in thumbs
Last modified: 2014-12-07 22:24:26 UTC
Currently we have the mouse scrollwheel zoom in on the window thumbnail, which to me feels more like a workaround to our sub-optimal layout for the window overview. It only scrolls the workspaces if hovering over the workspace switcher on the right. I would much rather see the behavior simplified to workspace switching regardless of the cursor position.
I agree with the suggestion : I fail to find an actual use case where the zoom would be useful. Related discussion : https://plus.google.com/118165493193465533929/posts/cQVUmFcUFZx
Created attachment 227009 [details] [review] workspace: Remove zooming of window previews Using the scroll wheel to switch workspaces makes sense, but it is currently only supported on the workspace switcher, as it conflicts with window zooming in the picker. As changing workspaces is far more useful than the zoom feature, remove the latter in order to "free" the scroll wheel for workspace switching.
Created attachment 227010 [details] [review] overview: Expose scroll-events Using the scroll wheel in the window picker should switch workspaces. As the picker doesn't have a visible boundary though, it makes sense to accept scroll-event for the entire overview area. Rather than making the overview's main actor public, expose scroll-events via a signal, similar to the existing swipe-scroll API.
Created attachment 227011 [details] [review] workspacesView: Allow workspace switching via scroll wheel This is already possible over the workspace switcher, extend this behavior to the entire window picker area.
Should we scroll search results globally as well, or confine them to the scrolling area? (In reply to comment #0) > Currently we have the mouse scrollwheel zoom in on the window thumbnail, which > to me feels more like a workaround to our sub-optimal layout for the window > overview. Thumbnails will never show much context. Most windows are black text on a white background. I use the zoom quite often to differentiate between windows, although maybe this would be mitigated with an application icon or other kind of hint. I wouldn't want to remove window zooming before we actually land overview relayout or app icons / other kinds of hints.
(In reply to comment #5) > Should we scroll search results globally as well, or confine them to the > scrolling area? > > (In reply to comment #0) > > Currently we have the mouse scrollwheel zoom in on the window thumbnail, which > > to me feels more like a workaround to our sub-optimal layout for the window > > overview. > > Thumbnails will never show much context. Most windows are black text on a white > background. I use the zoom quite often to differentiate between windows, > although maybe this would be mitigated with an application icon or other kind > of hint. > > I wouldn't want to remove window zooming before we actually land overview > relayout or app icons / other kinds of hints. Some options are: 1) Add a modifier key or 2) Zoom the previews a bit on hover ... not sure whether this would be "too busy".
*** Bug 694242 has been marked as a duplicate of this bug. ***
Created attachment 236897 [details] [review] workspace: Remove zooming of window previews Rebased to master.
Created attachment 236898 [details] [review] overview: Expose scroll-events Rebased to master.
Created attachment 236899 [details] [review] workspacesView: Allow workspace switching via scroll wheel Rebased to master.
Review of attachment 236897 [details] [review]: You can remove _clamp. I believe that's the only difference between my patch and this.
Review of attachment 236898 [details] [review]: Commit message needs fixing; there is no existing swipe-scroll API anymore. ::: js/ui/overview.js @@ +579,3 @@ + if (this._scrollEventId > 0) + this._group.disconnect(this._scrollEventId); + this._scrollEventId = 0; Why do we need to disconnect this signal? Shouldn't hiding the group be enough?
Review of attachment 236899 [details] [review]: Why are you making the view reactive instead of just letting the event bubble up?
(In reply to comment #13) > Why are you making the view reactive instead of just letting the event bubble > up? To have scrolling working on the whole view (including window previews) rather than just the background.
(Continuing on from bug 694242.) With the increase in size of thumbnails in general, thumbnail zooming does have less utility than before. I also really like Jakub's proposal for workspace switching. The current zooming behaviour is also really broken from an interaction point of view: you can zoom a thumbnail so it fills the entire screen, making it hard to escape, and the thumbnails lose their close buttons and outline. We could investigate other ways of doing zoom in a nice way - that would probably involve growing the thumbnail by a set amount, but I would like to know that zooming is really required (in light of the improvements to the thumbnail sizing in the 3.8 cycle) before we go down that route. Long story short: I think we'd be in a better position if we replaced scroll to zoom with scroll to switch workspace. If there's a real demand for zooming after 3.8, we can come up with a saner design than the current behaviour.
Created attachment 236913 [details] [review] workspace: Remove zooming of window previews Remove _clamp as well.
Created attachment 236914 [details] [review] overview: Expose scroll-events (In reply to comment #12) > Why do we need to disconnect this signal? Shouldn't hiding the group be enough? Yeah, shouldn't be needed ... (it made some sense to be consistent with the swipe-scrolling code when the patch was written, but as that code has been removed ...)
Created attachment 236915 [details] [review] overview: Remove some unused variables Those are left-overs from the custom swipe-scroll implementation.
Created attachment 236916 [details] [review] workspacesView: Allow workspace switching via scroll wheel This is already possible over the workspace switcher, extend this behavior to the entire window picker area.
Created attachment 236917 [details] [review] workspacesView: Remove some unused variables More left-overs from the custom swipe-scrolling code.
Review of attachment 236913 [details] [review]: OK.
Review of attachment 236915 [details] [review]: OK.
Review of attachment 236914 [details] [review]: OK.
Review of attachment 236916 [details] [review]: ::: js/ui/workspacesView.js @@ +491,3 @@ Lang.bind(this, this._onRestacked)); + if (this._scrollEventId == 0) + Main.overview.connect('scroll-event', Lang.bind(this, this._onScrollEvent)); Err you should actually assign the return value to this._scrollEventId otherwise this does not make much sense. @@ +715,3 @@ + if (!this.actor.mapped) + return false; + switch ( event.get_scroll_direction() ) { Why the whitespace?
Review of attachment 236917 [details] [review]: OK.
Attachment 236913 [details] pushed as 0e12215 - workspace: Remove zooming of window previews Attachment 236914 [details] pushed as c495ff8 - overview: Expose scroll-events Attachment 236915 [details] pushed as 2ac88a7 - overview: Remove some unused variables Attachment 236916 [details] pushed as af219ce - workspacesView: Allow workspace switching via scroll wheel Attachment 236917 [details] pushed as f83ad77 - workspacesView: Remove some unused variables
*** Bug 648140 has been marked as a duplicate of this bug. ***
Hi, was a plugin, switch, option, etc to reactivate this feature? I have just upgraded to 3.8 and I really miss it. (In reply to comment #1) > I agree with the suggestion : I fail to find an actual use case where the zoom > would be useful. > > Related discussion : > https://plus.google.com/118165493193465533929/posts/cQVUmFcUFZx This feature is (was) useful in 2 cases for me (others will probably have different reasons to want it): 1. if you have a few similar windows (editing a picture in Gimp) or have a few text editor windows (you can't read code in the thumbnails), you need to zoom to select the right one. 2. windows that keep changing such as emails, and chats. The thumbnails are too small to read anything, they are only useful to identify the window correctly. With the zooming I could go to the sheel, two clicks of the zoom were enough to see what was going on the chat, zoom back out and go back to work. On the G+ discussion being linked where this apparently started: > we probably should reconsider having the zoom feature. it's not all that > useful, and using it is often slower than going to the window and then > going back to the overview. This would only be true at all when zooming a window to fill the screen which I don't think is the point of zooming. If you have to scrool 10 times, then yes it would be slower but 2 is more than enough. Zooming is a lot faster than selecting the window. Finally, when you zoom back out, the other thumnails stay in the same place. If you select the window and then go back to the shell to pick another, the visual effects of all thumbnails "zooming" is more confusing than when all stay in the back and you only zoom one to check on it. All in all, this was a really nice feature and I'm sad to see it go. I get it one can write a separate extension but one could have also written an extension to have "scrolling on a thumbnail" change workspace instead of "zooming the thumbnail". This sentence from the commit message "Using the scroll wheel to switch workspaces makes sense" is true, but not when the mouse is hovering on a thumbnail.
I agree 100% with Carnë Draug.
Does it make sense to create a bug to get back that functionality? Let's vote? Really fix of current bug breaks backward compatibility idea. I suppose to create a new bug called "backward compatibility broken".
It seems I have found a compromise. tweak tool lets to disable dinamic work spaces,so the new feature implemented here becomes unnecessary. So, I suggest using zoom windows when dinamic workspaces disabled automatically. Or at least a user can choose between zooming windows and scrolling workspaces in tweak tool.
(In reply to comment #30) > Does it make sense to create a bug to get back that functionality? No, for the reasons given in this very bug report. Your new bug report would be correctly closed as WONTFIX. > Really fix of current bug breaks backward compatibility idea. I am not sure where you got the idea that GNOME 3.x core UI functionality is supposed to be "backward compatible" (whatever that means). If there is such a statement on an official GNOME page, please provide a link to it.
Well, you did anyway, and it was marked as a duplicate of bug 735661...