A11y guidelines for styles in core KDE - style devs, please read!

[Olaf Schmidt]

Hi!

I am about to leave for aKademy and won't be able to respond for a few days, 
but I can give some quick background information about the topic discussed.

> I am sorry, but this is simply technically broken. Styles draw primitives
> using the palette given to them in the style options, not some global,
> KDE-specific notion of a color scheme --- heck, they might be used by
> something that's not a KDE app at all. As such, any such 'helpful' colors
> may simply render things unreadable. Any solutions I can think of
> unfortunately may result in inconsistency of behavior.

Many styles currently use hard-coded colours, which are broken with 
light-on-black colour schemes. To fix this problem, we have extended 
KColorScheme to contain everything that is needed by styles and applications.

Applications must follow the global colour schemes in the palette they pass on 
to styles. Doing otherwise is an accessibility and usability bug and breaks 
the look and feel of the selected style/colour scheme artwork. If a style 
wants to also work for applications that don't follow this rule (e.g. non-KDE 
applications), then the style can use the new colour contrast evaluation 
function (which did not exist ion KDE3). Note, however, that almost all 
styles currently use hardcoded black for focus rectangles, so the situation 
can only improve.

> .. On top of the above, there are also aesthetic issues involved here:
> there is a certain visual vision involved in every style, and stuff like
> that can not be changed w/o the artist's aproval, IMHO.

We are not forcing style authors to change their styles. The new KColorScheme 
just helps style authors who care about accessibility and usability to 
achieve something that was impossible with KDE3.

> It's not a matter of "heard". It's a matter of -discussion-. Or, to put it
> bluntly, asking people who know the technical insanities involved in the
> matter one is trying to decide on.

The design of the extended colour schemes is a consensus between artists, 
accessibility people and usability experts in the HCI workgroup. It was 
discussed and agreed on with the Oxygen team leaders and later on 
kde-core-devel.

The HCI workgroup also asked Trolltech to change QPalette to allow additional 
colours, but they did not implement this change, so we have to live with this 
situation. We already had a mixture of palette colours and global colours in 
KDE 3 (e.g. toolbar highlight colour, now split into general hover and focus 
colours), so i am a bit surprised you suddenly see this as an "insanity".

I tried very hard to get feedback on these extended colour schemes by inviting 
artists in the HCI workgroup, by discussing this with all artists that where 
willing to give me feedback, and by posting this repeatedly to kde-core-devel 
over a period of several months. All of the code that Matthew refers to has 
been extensively discussed on kde-core-devel, so it is really unfair to 
accuse us of lack of communication.

Olaf