GNOME Bugzilla – Bug 648983
workspace opacity is wrong after canceled drag
Last modified: 2011-04-29 22:04:21 UTC
Steps to reproduce: 1) Have at least 2 workspaces (with at least one window on each) 2) Drag a window on workspace 1 and cancel the drag (i.e release the button) 3) Switch to the adjacent workspace 4) Notice that the opacity is wrong (it fixes itself after leaving the overview or imitating another drag action on that workspace). While debugging that I noticed that the code that is responsible for that bug is no longer needed (is from the pre overview re layout days) so it can be removed (see patch).
Created attachment 186907 [details] [review] workspacesView: Don't change opacity during dnd We used used to indicate to the user the ability to move to another workspace during dnd by highligthing the adjacent workspaces on hover. This was done by changing the workspace's opacity to 200 and set it to 255 for the highlighted adjacent ones. This is now no longer needed as the design was completely changed since then (overview relayout; we no longer represent workspaces in the way we did before) and introduces a bug where we don't properly reset the opacity after the drag action, so just remove that code.
Review of attachment 186907 [details] [review]: Looks good to me ("overview relayout" in the commit message is a bit generic, but OK - the decisive change was to increase the spacing between workspaces while zoomed out, so that adjacent workspaces are no longer visible - this was part of the vertical layout series, iirc)
Attachment 186907 [details] pushed as 56d584b - workspacesView: Don't change opacity during dnd