[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 309553] [Minimap] Problem with alternative colour scheme and widget misalignment
From:       Emmanuel Lepage Vallée <elv1313 () gmail ! com>
Date:       2012-11-10 22:42:28
Message-ID: bug-309553-17878-yDoCB9Vo3x () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=309553

--- Comment #8 from Emmanuel Lepage Vallée <elv1313@gmail.com> ---
The problems I have with the colours used for background and foreground is
inconsistency. Example:

http://ompldr.org/vZzgzcA

In this example, I have to point a few things:
*The slider background is black for C++ and red for Lua. Why? Because the color
order for those 2 languages is not the same. So alert is first in Lua and last
in C++. So, in the end, the foreground is totally arbitrary. But I love that
red! It may be an accident, but I like it. Too bad only lua have "alert" as
first colour...

*The "unseen area" background is also different. It create a few problem of
it's own:

------For C++, it ain't so bad. I guess you based your math on that one. For
Lua however, it is about as bright as the "content" so the brightness
differential index is so low that the brain have to focus to see the lines.  At
least mine do.

------In both care the brightness index of the scrollbar is much higher then
the code area. This is problematic for many reasons. (it is the opposite in
brighter palette, and in that case, it ain't so bad)

------------First that is high contrast is usually bad for the eye because
switching focus between bright and dark area on a screen too often cause the
pigment that allow us to see in the dark to be "burned" to turn out vision into
day light one. But when focusing back on the dark area, our eye rush to create
those things again. Doing that too often will hurt the eye night vision
permanently. http://en.wikipedia.org/wiki/Night_vision#Biological_night_vision

------------Second, more related to usability, is the reason why professional
multimedia application use dark colours palette. It allow to eye to quickly
focus on content, like video editing focus on the video itself. On pure bright
application, eye is overwhelmed by light, so it focus on the application rather
than part of it. By creating out of control brightness differential between the
text canvas and scrollbar, you accidentally create such a focus hub. 

While the problem is not present with Oxygen default color palette and while
looking at C++, the current color model does not scale beyond those default
settings. My opinion would be to use the palette().base().color() or Kate
current text background colour as background and using use a brightness index
averaging the document brightness index on the "mini-lines" to make sure the
scrollbar is not distracting. And for the slider background, just adding a
config option, the current one is just as random as it can get. It also void
the palette in both dark and bright mode (in birght/light mode, bitghter is "on
top" while darker is "below", see the normal scrollbar for an example of
that.). But then, it may be a good idea to have a little bigger pool of
opinions.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]