GNOME Bugzilla – Bug 646704
Single window in "Activities" overlay looks usable
Last modified: 2012-03-22 18:46:41 UTC
Application windows in the activities overlay look usable, but are not. * Single application window (example: Empathy chat window) is open on a workspace. * Activities overlay is displayed. * Application contents are updated as a normal window would. ie: videos play, new chat content shown. * User tries to type in the window. Application disappears and is replaced by 'No matching results' The clues that the window is not actually usable are very subtle: * The window may be blurry and slightly smaller than usual. * There may be an (X) on the corner, if the user's mouse is over the window. * There's some icons and stuff displayed on the sides of the screen. I can make screenshots if necessary. Not sure of the exact gnome-shell version. Is there an easy way to show an about dialog?
What cues might provide a better suggestion of what's happening? Off the top of my head: Render the windows as cards at a slight angle: |\ |^^--__ | \ | | | | | | | | | | | | | | | / | | |/ |__--^^
I've seen this problem on a number of occasions - the window thumbnail isn't scaled down enough for the user to realise that they cannot interact with it. It doesn't just happen with single windows, either - it can occur with smaller windows that haven't been scaled down too. This can be extremely disorientating for users. The easiest way to deal the problem might be to set a minimum level for scaling down the thumbnails.
I'm new to this but I was thinking perhaps using something like the 'overlay icon extension' provides but be meaningful enough to explain it isn't usable. Basically you have an icon that represents the app running, in the center of the 'window', and when you hover over it, it becomes translucent. As Allan said, implementing a scaling minimum would be easier though.
Created attachment 204417 [details] [review] scaling minimum patch It took me about an hour browsing through the code to find the place where one number must be changed. I've tried different values of scale ratio. 0.8 looks still usable to me, so I've gone for 0.7
(In reply to comment #4) > Created an attachment (id=204417) [details] [review] > scaling minimum patch > > It took me about an hour browsing through the code to find the place where one > number must be changed. I've tried different values of scale ratio. 0.8 looks > still usable to me, so I've gone for 0.7 Hey Vít, thanks for looking at this! Can you provide a patch and not a diff, please? There are guidelines here [1]. [1] https://live.gnome.org/GnomeLove/SubmittingPatches
Created attachment 204827 [details] [review] patch My previous diff in patch format.
On the design side of things, Mac OS X colors window thumbnails in blue when hovering on then, and the pointer looks like a hand rather than like the normal cursor. This is probably made to prevent thumbnails from looking like usable windows. I'm not sure we want to adopt these ideas too, but at least some kind of coloration could also help fixing this bug. Just an idea.
(In reply to comment #6) > Created an attachment (id=204827) [details] [review] > patch > > My previous diff in patch format. TBH I don't like this solution at all ... we shouldn't downscale if we don't have to.
(In reply to comment #6) > Created an attachment (id=204827) [details] [review] > patch > > My previous diff in patch format. Looks good to me! This helps to communicate that the images are thumbnails, but they're still big enough to identify. (In reply to comment #7) > On the design side of things, Mac OS X colors window thumbnails in blue when > hovering on then, Hovering a thumbnail adds a coloured border, which is something we're aiming for in bug 665310. > and the pointer looks like a hand rather than like the normal > cursor. ... Really? I see no evidence of that [1]. Seems like an odd idea` to me - a hand would indicate dragging or panning, not selecting. (In reply to comment #8) > (In reply to comment #6) > > Created an attachment (id=204827) [details] [review] [details] [review] > > patch > > > > My previous diff in patch format. > > TBH I don't like this solution at all ... we shouldn't downscale if we don't > have to. Can you explain why? I don't see the problem myself; they're thumbnails, after all, and they are still identifiable at 70% size. [1] http://youtu.be/EHLnjzX6lX4?t=1m46s
(In reply to comment #9) > (In reply to comment #6) > > > > > > > My previous diff in patch format. > > > > TBH I don't like this solution at all ... we shouldn't downscale if we don't > > have to. > > Can you explain why? I don't see the problem myself; they're thumbnails, after > all, and they are still identifiable at 70% size. Because down scaling comes with a cost (it looks simply worse) so it should be only done when we have to do that (space constraints) not just to make them visually distinct from the original.
(In reply to comment #9) > Hovering a thumbnail adds a coloured border, which is something we're aiming > for in bug 665310. Good. > > and the pointer looks like a hand rather than like the normal > > cursor. ... > > Really? I see no evidence of that [1]. Seems like an odd idea` to me - a hand > would indicate dragging or panning, not selecting. > > [1] http://youtu.be/EHLnjzX6lX4?t=1m46s So they must have removed them in Lion - I only saw Snow Leopard. Maybe they understood it's not a good idea. ;-) Anyway, the hand was more like the one used for hyperlinks than for dragging (but I didn't say it was something to implement ourselves).
I spoke to Jimmac about this the other day. He agreed with the patch (albeit begrudgingly ;) ).
Review of attachment 204827 [details] [review]: Code looks obviously correct. I can't make much sense of the subject line in the commit message, I'd suggest something like "workspace: Set a maximum scale for window clones"; also s/beacause/because/ in the body. ::: js/ui/workspace.js @@ +988,3 @@ let scale = Math.min((width - buttonOuterWidth) / rect.width, (height - buttonOuterHeight - captionHeight) / rect.height, + 0.7); While 1.0 is a "natural" value (read: full size), 0.7 is not, so it may be a good idea to define a constant at the top of the file and use it here.
Created attachment 205301 [details] [review] patch (In reply to comment #13) > Review of attachment 204827 [details] [review]: > > Code looks obviously correct. > > I can't make much sense of the subject line in the commit message, I'd suggest > something like "workspace: Set a maximum scale for window clones"; also > s/beacause/because/ in the body. > > ::: js/ui/workspace.js > @@ +988,3 @@ > let scale = Math.min((width - buttonOuterWidth) / rect.width, > (height - buttonOuterHeight - captionHeight) / > rect.height, > + 0.7); > > While 1.0 is a "natural" value (read: full size), 0.7 is not, so it may be a > good idea to define a constant at the top of the file and use it here. You're right.
Review of attachment 205301 [details] [review]: Looks good. Do you have git access or do you want me to push the patch for you?
(In reply to comment #15) > Review of attachment 205301 [details] [review]: > > Looks good. Do you have git access or do you want me to push the patch for you? I don't have git access. It's actually my first bugfix :-), so if you'd be so kind...
Excellent! Thanks for the patch Vít!
Honestly, this seems very temporary. As, downscaling as someone else mentioned does not fix the original problem. On larger displays, the windows still appear usable.