GNOME Bugzilla – Bug 662087
Use a more visible cue to highlight the active workspace
Last modified: 2012-08-28 20:19:24 UTC
[Summary] The visual cue provided by the shell to indicate the active workspace is too subtle to be seen at a glance. The overview mode of gnome shell is one of the ways for finding a specific window for an open application. After prolonged use, your windows can become quite unpredictably distributed across a number of workspaces. It is a common occurence to go to the activities window with the intention of examining a workspace that looks like one which may contain a window you are interested in. You click on the said workspace and find yourself brought back to the default work mode of the shell because you clicked on the same workspace as the one you are currently in. Perhaps a glowing highlight of a more contrasting colour, say "yellow" would make it easier to identify which is the active workspace without requiring a considerable amount of concentration.
Rather than introducing new color, I recommend going "4px solid rgba(255,255,255,0.7) that turns into #fff when the workspace becomes a drop target. http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-window-picker-6-workspaces.png?id=0b207b9784f5bf1e15fb5ece653020aa5220d95b
I think contrast is a useful quality to have in this situation, since that colour looks a lot like the windows themselves at that scale (particularly on a busy workspace). BTw, where do you make the change to the colour and border thickness? I looked around various css files in /usr/share/gnome-shell but couldn't find a property that allowed me to tweak the box.
Created attachment 202216 [details] [review] Make workspace selector more similar to mockup This make the workspace indicator respect the "padding" style attribute. We use this to make the workspace selector more similar to the mockups.
Review of attachment 202216 [details] [review]: I'm confused. Shouldn't the adjustments in st-theme-node.c (see: get_preferred_width, get_preferred_height, get_content_box) already make sure that padding is respected?
Review of attachment 202216 [details] [review]: Oh, I see, nevermind. We don't actually call get_preferred_width/get_preferred_height to get the indicator's size, we just allocate it. This seems good to me.
Created attachment 202229 [details] [review] Make workspace selector more similar to the mockup This makes the workspace indicator respect the "padding" style attribute. Also, since we no longer draw the border on top of the thumbnail, we need to be pixel-precise in allocating the indicator height. We use this to make the workspace selector more similar to the mockup.
Created attachment 202246 [details] [review] Make workspace selector more similar to the mockup This makes the workspace indicator respect the "padding" style attribute. Also, since we no longer draw the border on top of the thumbnail, we need to be pixel-precise in allocating the indicator height. We use this to make the workspace selector more similar to the mockup.
Review of attachment 202246 [details] [review]: What did you change here?
(In reply to comment #8) > Review of attachment 202246 [details] [review]: > > What did you change here? I moved the definitions of the indicator borders before the iteration over the thumbnails. Here it is the same, but it is required for the patch in https://bugzilla.gnome.org/show_bug.cgi?id=664204
Change it with a patch in that bug, then.
Review of attachment 202246 [details] [review]: This looks fine to me.
Patch got committed, closing.