GNOME Bugzilla – Bug 634599
show application-icons in the overview
Last modified: 2016-02-08 22:28:27 UTC
because the windows in the gnome-shell-overview often moves with opening and closing windows/applications, it would be easier to find the window you want to use. Especially for windows with has very dynamic content (like webbrowsers) it would be a big advantage.
Created attachment 174261 [details] mockup
We used to do this, basically exactly like in your mockup, except over the lower-right corner instead of upper-left, but they were removed on the grounds that they were distracting or something.
*** Bug 646822 has been marked as a duplicate of this bug. ***
Created attachment 185890 [details] mockup for small icons in window titles
I hope it's ok if I just add that I very much hope the overview icons come back. On my 1024x768 screen it's very difficult to tell the difference between a lot of overview windows, and icons would help a lot.
The extension is ready here: https://github.com/yuyichao/gnome-shell-overview-icon You can adjust icon position and size directly in the code. I've changed it a bit to show icons near the window titles: https://github.com/bookwar/gnome-shell-overview-icon
Thanks for the extension. I vote for including this feature in the shell.
(In reply to comment #2) > We used to do this, basically exactly like in your mockup, except over the > lower-right corner instead of upper-left, but they were removed on the grounds > that they were distracting or something. I'd be interested to hear about why they were removed. The icons seem like they could be useful, and are used to good effect in OS X. Jon - can you comment?
*** Bug 665651 has been marked as a duplicate of this bug. ***
The alternate solution is bug 661042: color-code windows per application.
They were removed for a few reasons. In the design at the time they were competing with the application icon use in the what was the application well. Jeremy and I found that they were distracting from identifying the window by its appearance - particularly so since the windows weren't always at high enough fidelity or large enough. We wanted to see if the design would work without the crutch. Another reason is that it didn't really work well to tag each window with the application icon if there was no application grouping of windows. There were also way way too many app icons in the overview. Also, we wanted there to be consistent behavior with how the application icon was used in the desktop. For example, clicking on the application in the dash would bring up the application. Clicking on the application in the application switcher did the same. It is a bit of a problem if clicking on the application icon in the window switcher did something very different. The OS X mission control works for me in part because the windows are grouped by application.
That said, there is room to explore the idea further and I'm not completely opposed to it. After all it was in the original design. We'd just have to make sure some of the concerns are addressed and not just use the naive implementation we had.
I will have to say that on my laptop (widescreen 14.x inches), it is often very hard to find out what window I am needing, esp if the Title in the window is long (eg, Firefox isn't listed because the window title was so long). Sometimes it is hard for me to tell the difference between LibreOffice windows and gEdit windows, etc. Lifrea vs other things, and so on. I do like the idea of putting the icon before the lettering underneath the window icon. It sure looks slick and draws the eye to one location.
*** Bug 615361 has been marked as a duplicate of this bug. ***
after using the extension, I must say that it vastly improved my own experience of gnome-shell. As William pointed out, having consistency is a paramount. But, in the case of the extension at least, it is very consistent as clicking on the icon bring the application. Another point that should be explored, IMHO, is to do the same on the workview switcher. Currently, it is very hard to see what you have on a given workspace (a white rectangle, how original). Compare that with some screenshots of the older workspace switcher: http://ploum.net/images/gpager.png As you can see, even though the pager is a lot smaller, it is a also a lot more evident what each workview is about. I think that by adding the icons on the thumbnails, we can bring the best of both world.
(In reply to comment #6) > The extension is ready here: > https://github.com/yuyichao/gnome-shell-overview-icon > You can adjust icon position and size directly in the code. > > I've changed it a bit to show icons near the window titles: > https://github.com/bookwar/gnome-shell-overview-icon I'm liking it. Works just great for me. Glad to have this even if it isn't accepted in any other way but an extension.
I've tried the icon overlay extension [1]. Although it is a functional improvement, it leaves you in a sea of icons. It's not an elegant solution, and I suspect it would be bewildering for a new user. Having smaller application icons in the window thumbnail titles could be a better approach. The extension referenced in comment #6 does not seem to implement this, at least when I tried it. However, it seems from bug 661042 that Jasper has code to do it. It'd be nice to be able to try that. [1] https://extensions.gnome.org/extension/60/overlay-icons/
Hi Allan, I believe that "a see of icons" is a lot better than "a see of white rectangles" (which is the case without the extension). But I 100% agree that it could be made more elegantly, with smaller icons, maybe in a corner of the thumbnails instead of the middle. I don't know, those are design consideration and I suck at design ;-) One thing I'm sure is that having the icons really help in term of recognition.
(In reply to comment #18) > But I 100% agree that it could be made more elegantly, with smaller icons, > maybe in a corner of the thumbnails instead of the middle. That's sounds pretty much like what we had when icons were removed, see http://bugzilla-attachments.gnome.org/attachment.cgi?id=145374
I can't believe how quickly people forgot this feature from the pre 3.0 days... technically, bug #615361 should have been reopened and this bug marked a duplicate of it, it would have been more historically accurate ;) The question will thus be: who decided to remove the icons initially, on what grounds? If the icons were removed and my bug report closed because it "was a design decision [...] and the shell is working as expected", and it turns out that many people actually disagree with that decision from back then (not just me), then I expect a fair amount of explanation from the design team this time around.
(In reply to comment #20) > I can't believe how quickly people forgot this feature from the pre 3.0 days... > technically, bug #615361 should have been reopened and this bug marked a > duplicate of it, it would have been more historically accurate ;) > > The question will thus be: who decided to remove the icons initially, on what > grounds? ... Jon has provided some background to the decision to remove the icons in comments #11 and #12 above.
*** Bug 669221 has been marked as a duplicate of this bug. ***
*** Bug 648994 has been marked as a duplicate of this bug. ***
*** Bug 691116 has been marked as a duplicate of this bug. ***
Created attachment 246367 [details] Two methods of generating window miniature Some windows scale down very well. These are usually photos, videos, colorful websites and the like. Others scales down to white rectangles. This is mostly text. So maybe more sophisticated (selective) method of scaling is needed. The method that do know what to scale or not. Plus choosing the most essential information and leaving out window chrome and other supplementary content. See the attachment and judge what window thumbnail gives more rewarding and pleasant experience.
*** Bug 651022 has been marked as a duplicate of this bug. ***
Please consider to use: 1) Depending on the number of windows in the actual workspace No Icons are required, because the size of thumbs are enough to find the correct one. 2) When the number is five to six, icons could be useful but not all. 3) A predictable location is better when windows are opened or closed. See at: https://bugzilla.gnome.org/show_bug.cgi?id=613453#c6
I'm going to go out on a limb here, and say that this isn't something we want. We've tried the idea in several different formulations, and a few of us have independently decided that it's not something we want. I think the fundamental issue is that so many application icons introduce an unhealthy amount of visual noise into the window selector. What we have done is improve the layout of the thumbnails to increase their size, and I think that this has significantly reduced the original problem - that is, the difficulty of identifying window thumbnails. This is the ideal use for an extension.
*** Bug 728784 has been marked as a duplicate of this bug. ***
*** Bug 742584 has been marked as a duplicate of this bug. ***
Well, I think we all agree that scaled down windows of a text editor, a browser showing a mostly blank web page, a terminal window with a light background and a word processor with not too much text all look very similar -- confusingly similar, as this is what this bug report is about in the first place. So, maybe an algorithm could be added that detects "mostly blank" windows and -- instead of scaling them down in the overview mode -- *crops* them to decrease their size [1]. Thus, part of the actual window content would still be visible in the downsized versions in the overview mode, and windows could be easier distinguished from each other. What do you think? - Fabian [1] or, a combination of both, e.g. resize not smaller than 50%, then crop to the most non-white rectangle
*** Bug 761680 has been marked as a duplicate of this bug. ***