GNOME Bugzilla – Bug 665310
highlight window thumbnails on hover
Last modified: 2012-12-10 22:19:59 UTC
We already show the close button when the pointer is positioned over the window thumbnail. It would be great to visually highlight the thumbnail too - this would give a nice bit of feedback that it is clickable. Here's a mockup: http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-6-workspaces.png Bug 664204 requests a similar effect for workspace thumbnails.
Created attachment 204214 [details] [review] Highlight of the title when the window is hovered First step done: the title is highlighted when the window is hovered. The second part will be highlighting the window itself.
Review of attachment 204214 [details] [review]: This is a good patch, for a priority bug in Every Details Matter. Why was it blocked until after UI freeze?
(In reply to comment #2) > Review of attachment 204214 [details] [review]: > > This is a good patch, for a priority bug in Every Details Matter. > Why was it blocked until after UI freeze? I think I was probably waiting for the second part, but yes, my bad for not following up. Giovanni, this doesn't apply to master. Even when I've made it so that it does apply, it doesn't seem to work. Have you tried the patch?
(In reply to comment #2) > Review of attachment 204214 [details] [review]: > > This is a good patch, for a priority bug in Every Details Matter. > Why was it blocked until after UI freeze? Such patch, if it does work with the master, could be made complete if combined with the functionality of such extension: https://extensions.gnome.org/extension/60/overlay-icons/ The bonus is making the window overview much easier to distinguish the different open windows, which would help close the following bugs (although I might have missed some): https://bugzilla.gnome.org/show_bug.cgi?id=663398 https://bugzilla.gnome.org/show_bug.cgi?id=651022
Marc, do you have a git account? If not, I can push the patch for you, now that we're out of hard code freeze. This is a good candidate for 3.4.1.
(In reply to comment #5) > Marc, do you have a git account? If not, I can push the patch for you, now that > we're out of hard code freeze. This is a good candidate for 3.4.1. Is this not a UI freeze break? The UI freeze still applies for 3.4.x.
OK, now we're out of UI freeze break.
Patch status has been "accepted-commit_after_freeze" for more than 3 months now. Which exact freeze does this refer to? Can this get committed, or should the patch status be updated?
Comment 3 seems to indicate that it doesn't work ? Giovanni, Jasper whats the status here - has the patch been updated to apply, and has it been tested to work ?
(In reply to comment #9) > Comment 3 seems to indicate that it doesn't work ? If I recall correctly, the patch applies a border to the window title on hover. While this is good, a border also needs to be applied to the thumbnail at the same time. The latter is the most important part of the design, and it doesn't make sense to land the current patch without it.
Created attachment 222949 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> Rebased, updated, and added borders to the window.
Created attachment 222953 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> Fixed a small jump in the animation to and from the overview.
Created attachment 226689 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> I essentially rewrote the patch from scratch to put the code in WindowOverlays, instead of adding great hacks to the layout code to account for the borders (or worse, have the borders scale with the windows)
Created attachment 227179 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> Rebased on the new window layout.
I don't seem to be able to apply this (can't tell whether I messed something up or not).
Created attachment 228157 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> It applies fine here. Anyway, this is rebased on current master.
Created attachment 228168 [details] [review] hacked patch Thanks Giovanni! I've modified the patch a bit and it will need fixing since there is unnecessary code now. I actually removed the border color change - I think it looks better without, tbh.
Created attachment 228169 [details] screenshot So I quite like this, but it feels a bit jerky. Would it be possible to fade the border in and out? Jon, Jimmac: what do you think?
Created attachment 228188 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> This time with animations. Doesn't seem to make much difference, unless it is artificially slowed down.
This needs design review from Allan.
Comment on attachment 228188 [details] [review] Workspace: Highlight window clone and caption when hovered It also needs me fixing the animation of the border when starting a drag.
Created attachment 228426 [details] [review] Workspace: Highlight window clone and caption when hovered Windows in the overview should be highlighted when hovered, to indicate they are an active target. Based on a patch by Marc Plano-Lesay <marc.planolesay@gmail.com> ... which I just did. Still, this patch shows one curious point: the effect on hover is very different if the primary color of window is not clear, eg. for dark themed window. In particular, the effect on corners for dark windows is strong. Also, but that's a minor issue, border corners are always the same width, while those of the windows vary with scale, so they don't always blend nicely (this becomes noticeable because the background is dark)
Here's a screencast so Jon and Jimmac can take a look (I tweaked the patch for this - it's using a 4px border): https://dl.dropbox.com/u/5031519/gnome-shell/Screencast%20from%2011-09-2012%2007%3A59%3A39%20PM.webm
Bikeshed: I think we should adjust the position of the close button to take the border into account.
I also wonder if we should use the patches in https://bugzilla.gnome.org/show_bug.cgi?id=661042 to generate a color for the window based on the app icon.
(In reply to comment #23) > Here's a screencast so Jon and Jimmac can take a look (I tweaked the patch for > this - it's using a 4px border):... I've had a chat with Jimmac about this - he's happy with this if the positioning of the close button is fixed. We also discussed maybe using a glow effect instead of the border. I tried modifying the css to use a box-shadow instead of the border but it didn't seem to work...
Ping. :) We just need the close button to be fixed for this, I think.
Created attachment 229459 [details] [review] updated patch Seems that the close button placement is defined in the css. :) Here's an updated patch with the styling changes folded in.
Pushed. Code was reviewed in the previous iteration, I'm assuming the design was checked, given the author of the latest patch :)
Created attachment 230824 [details] gap issue at the top of the window Seems that there's a issue with this patch, there's a gap between the window and the top of the highlight. It is noticeable when you have only one window in a single workspace and the window is very little.
Somehow, I had a feeling that eventually that bug would surface again. That is a combination of bad coordinate rounding and the window texture including some trasparent border. I had a few iterations locally with multiple ways to address this, but each had its set of problems (some with maximized windows, some with small windows, some with stretched...), so in the end I went for the no rounding at all option. I'm not sure which way is the best one.