GNOME Bugzilla – Bug 661042
Color-code the overview based on application icon
Last modified: 2012-03-18 01:17:30 UTC
Sort of implementing the mockup here: https://github.com/gnome-design-team/gnome-mockups/raw/master/shell/tints.png Screenshot in action: http://i.imgur.com/5Tk6W.jpg Thanks a ton to pippin for helping me with the algorithm to extract the color.
Created attachment 198391 [details] [review] shell-app: Add a new utility method for grabbing pixbufs
Created attachment 198392 [details] [review] shell-app: Add algorithm for grabbing icon color This is a basic 3D histogram for pulling out the "most prominent color" from a pixbuf. This will be used to color-code application-specific things based on its icon. Thanks a ton to pippin for giving me the details of the algorithm to work with, explaining a lot of things and just being a nice person in general.
Created attachment 198393 [details] [review] workspace: Colorify the window overlay labels Put an icon to the left of the label and color-code the labels based on our new prominent color algorithm.
Created attachment 198394 [details] [review] shell-app: Add a new utility method for grabbing pixbufs
Created attachment 198395 [details] [review] shell-app: Add algorithm for grabbing icon color This is a basic 3D histogram for pulling out the "most prominent color" from a pixbuf. This will be used to color-code application-specific things based on its icon. Thanks a ton to pippin for giving me the details of the algorithm to work with, explaining a lot of things and just being a nice person in general. Fix accidental rebase "in the wrong patch" issue.
Created attachment 198396 [details] [review] shell-app: Add algorithm for grabbing icon color This is a basic 3D histogram for pulling out the "most prominent color" from a pixbuf. This will be used to color-code application-specific things based on its icon. Thanks a ton to pippin for giving me the details of the algorithm to work with, explaining a lot of things and just being a nice person in general. -- Remove a thinko (thanks pippin!), up the bin and icon sizes for a more accurate scan
What about changing the color of the "running indicator" in the dash too? That would make it easier to match an application with its window, and make the overview more consistent. (Just an idea, one would have to check whether it looks good or not...)
Hi Jasper, Perhaps a personal comment, but rather coloring the whole background label, I would color the outer border's label. The win would be the color of the font would be consistent, and makes less harder to switch between each application. I'm a curious, but why don't you implement the color around the application border as define is the initial mockup ? Regards.
(In reply to comment #8) > Hi Jasper, > > Perhaps a personal comment, but rather coloring the whole background label, I > would color the outer border's label. > The win would be the color of the font would be consistent, and makes less > harder to switch between each application. > > I'm a curious, but why don't you implement the color around the application > border as define is the initial mockup ? Because it's "harder to do". I tried a few times, but never got anything to work. I'm not seriously suggesting that we take the label patch -- it was just to show off the color extracting algorithm.
The colors in the mockup are prettier than the colors in the screenshot... Admittedly, the firefox color in the mockup is obviously too orange (relative to the icon), but the color in your screenshot is both too red and too brown. Likewise, the xchat color is also too brown. (Note how the banshee and emacs colors bleed into their respective icons, but the firefox and xchat ones very clearly don't.) I don't know what that translates to algorithmically... (but cool idea)
(In reply to comment #10) > The colors in the mockup are prettier than the colors in the screenshot... > > Admittedly, the firefox color in the mockup is obviously too orange (relative > to the icon), but the color in your screenshot is both too red and too brown. > Likewise, the xchat color is also too brown. (Note how the banshee and emacs > colors bleed into their respective icons, but the firefox and xchat ones very > clearly don't.) I darkened the color just a bit to give a bit of contrast. Here they are "undarkened" (also imgur seems to be jpegifying the screenshot, not good): http://magcius.mecheye.net/shell/overview-undark.png It bleeds more, but IMHO it's ugly in the case of Firefox. Additionally, we're using two different icon sizes: in the label, we're using the 16x16 (not pixel aligned because this is a five minute hack). To grab the actual color, I'm scanning the 64x64 icon. If the two are radically different, this will result in a mismatch.
(In reply to comment #11) > It bleeds more, but IMHO it's ugly in the case of Firefox. Maybe that's because you fill a whole area with that color? It could look nicer if there was a more subtle effect. For example, you could keep the original idea from the mockup, but use a gradient so that the color is only a glow around the window. Or, if that's too difficult, do that, but around the window title, just to try.
(In reply to comment #11) > It bleeds more, but IMHO it's ugly in the case of Firefox. the color is ugly or the bleeding is ugly? of course if you switched to the border-color thing like in the mockup then there wouldn't be any bleeding either way. bug 650254 has some work towards bubble-borders like in the mockup
Created attachment 199857 [details] [review] workspace: Add colored borders around windows in the overview Put an icon to the left of the label and color-code the borders based on our new prominent color algorithm, as per Hylke's mockup: https://github.com/gnome-design-team/gnome-mockups/raw/master/shell/tints.png Implement the mockup for real this time Requires a patch to Clutter to work correctly, otherwise we'll crash when reparenting the StGroup (either due to DND or window zooming): https://bugzilla.gnome.org/show_bug.cgi?id=662634
Screenshot: http://i.imgur.com/5eHWf.jpg
Hi Jasper, I'm nit-picking a little bit, but the outer border (1px) could be darker as specified in the reference mockup; and the round corner seems to be aliased (perhaps caused by the image compression). As a side note, you linked the reference mockup, but what is the reference document, because I would like to look to it to see what motivated this feature. Thanks for your work.
The mockup motivated this feature. I said I was having trouble identifying windows in the overview, and Hylke came up with this in #gnome-design. The trouble with the aliasing is because the actor is scaled.
Designers, comment on this one? I just closed yet another request to bring back applications icon, and this patch looks like a very good way of making these users happy and improve the general usability.
Last I heard, they didn't like the "angry fruit salad-ness" of it. It's also not the best implementation of the idea.
The alternate solution is bug 634599: show application icons on the thumbnails.
Jasper - the implementation here is clearly too heavy. If we want to try showing the tint for every window, I would suggest trying to display it in a subtler manner. You could apply it to the lower edge of the window like Chrome does it, or you could even use the colour in the caption bubble in some way. (In reply to comment #20) > The alternate solution is bug 634599: show application icons on the thumbnails. You're right that these two bugs are related. App icons, particularly large ones, might mean that tints aren't so useful. You could still potentially combine tints and smaller app icons though. Another possibility would be to show app icons and use the tint for the focus highlight (bug 664204). This is something that could be nice to experiment with as an extension until we are happy with it.
Some of the patches here may be pulled for something else, like a tint highlight. But we're not implementing the suggestion in this bug report.