Re: Color coding in gnome-shell

[Peter Goetz <peter gtz gmail com>]

2011/5/31 Peter Goetz <peter gtz gmail com>:
> Hi Florian,
>
>> Hi Peter!
>>
>> I'm not a developer but I experienced the same problem.
>>
>> 2011/5/28 Peter Goetz <peter gtz gmail com>:
>>> There is only one thing, however, that I think could be improved and I
>>> would like to hear you guy's opinion on it. Here's the problem:
>>>
>>> Whenever I have more than 6 windows open and most of them are Firefox
>>> windows with a white background it's very difficult to easily spot the
>>> window I am looking for when I'm in the activities view. And it
>>> doesn't even have to be only Firefox windows, even my Eclipse window
>>> with its white background is hard to find too. So I spend a lot of
>>> time searching for windows.
>>
>> I face that problem very often, especially when using the standard
>> grid overview. When using non-fullscreen windows, such as nautilus
>> folder views the native-window-placement extension brings some
>> improvements.
>>
>> http://git.gnome.org/browse/gnome-shell-extensions/tree/extensions/native-window-placement
>
> Nice! Haven't seen this. I'm pretty sure it improves the situation,
> unfortunately I couldn't test it yet. Somehow the version in the
> extension and my gnome-shell version do not match and fixing it in the
> extension makes gnome-shell crash during startup.

Tried it again today and it suddenly works. Not sure why it crashed
before. Anyways, changing the version number did the trick. This looks
great! I have to use it for some time in order to have a real opinion
of course. But what I can already see, is, that it really works nicely
with non fullscreen windows. Fullscreen windows are still somewhat
difficult to identify it seems. But the positions strategy is probably
still better than the colors...

Anyways, thanks for this great extension!
Peter

>
>> Instead of using colors, windows can be found more easily by their
>> size/position.
>> If the fixed position could be improved for fullscreen windows, this
>> could help sufficiently (for me at least ;-)).
>
> I definitely agree, positions are even better than colors! It would be
> interesting to have an algorithm that roughly keeps the positions of
> windows, even when the number of windows increases or decreases.
>
>>> One thing I noted though, whenever I look for my gedit window, I can
>>> easily spot it. It's because it has a blue background.
>>
>> I don't have the blue background by I easily spot it because of the
>> gray background of the new iconbar. But as soon as every native Gnome
>> application uses this style, the feature will be gone.
>>
>>
>>> So I was wondering if it would be a good idea to introduce some color
>>> coding in gnome-shell, similar to those Firefox tab extensions that
>>> color the tabs in different colors. That would mean, when in the
>>> activities view, every zoomed-out window is overlaid with a color, or
>>> there could be colored colored bar next to the zoomed-out window, so
>>> it's immediately recognizable. I think it's not necessary that the
>>> color mapping is permanent across different login session, I think it
>>> would be enough if the mapping is fixed for a one session.
>>
>> I'm wondering if using the color in overview will be enough. It could
>> be more consistent to have the color coding when switching
>> non-fullscreen windows by clicking them or in Alt-Tab as well.
>
> Yes. I even thought about having the same color in the title bar of a
> window. But it's probably not practical.
>
>> The negative point of this is, that colors disturb if you are doing
>> color-sensitive work like image manipulation. Anyway colors have
>> psychologic influences, so if the colors are too present, they could
>> become annoying.
>
> Yea, that's the biggest problem I see with colors too, which is why
> I'm not completely happy with the idea.
>
>> For further discussion and better reaching the devs you can file a
>> bug. (Check for existing ones before!)
>
> Okay. Will do! Let's see if anyone picks up the idea. I was actually
> hoping for more feedback here on the list. But we'll see.
>
>> Florian
>>
>