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

[Matthew Woehlke]

Maksim Orlovich wrote:
> First of all, thanks for starting up this thread.
>> The usability group has recommended that widgets that currently have
>> input focus be drawn in a different manner using a designated color
>> which is (currently) part of KColorScheme.
> 
> 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.

That argument is ridiculous. We're not talking about doing anything 
that's any *more* broken then what styles are already doing. Rather, 
we're centralizing functionality which is currently haphazardly 
implemented. Also, if styles can use kdeui, they can also use KDE 
utilities to help *avoid* problems (for instance, we could /turn off/ 
such colors if we detect that the widget is using a non-standard 
palette), which would be an improvement over the current situation.

>> And we're also attempting to
>> standardize the color used to indicate widgets that can currently be
>> clicked (i.e. the "hover" color).
> 
> .. 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.

See clarification points. There are a11y objections to your view, but at 
any rate, making common colors available at the system level is 
improving usability by providing one central place to change colors 
/that styles are already using/. Right now, you have to change focus and 
hover colors for every style (if they even allow you to change them), 
and then do it all over again if you change your color scheme. 
KColorScheme significantly alleviates this problem.

>> There are two problems: one, apparently none of the style developers has
>> heard about this until now,
> 
> It's not a matter of "heard". It's a matter of -discussion-.

I'm not sure what you mean. If people knew about the decision, and 
objected to it, why is this the first *I* heard about it?

>> and two this currently requires styles to
>> link to kdeui (which reportedly causes crashes). So this is an attempt
>> to get the right people reading and involved in the conversation.
> 
> More accurately, which caused crashes back when kdefx was created, in 3.0.
> Mind you, linking isn't the only issue: things shouldn't assume that a
> KApp or a KInstance are around, but that's probably not a big deal these
> days.

Right, I'm hoping we can figure out a solution. Otherwise I think that 
some things currently in kdeui need to be moved to kdefx, or they will 
be DOA, and we don't want that :-).

>> We need to figure out some resolution, and if it involves API changes,
>> we need to figure one out *fast* (else at best we already have dead
>> API's in kdeui).
> 
> I thought the requirement has always been to have users for classes before
> they move to kdelibs, so how can we have dead APIs?

...because this is the first I heard that the things (styles) that were 
going to use this, can't? :-)

Plastik is supposed to be a user, as are other styles*, but I've just 
learned that (currently) styles can't use kdeui :-(.

(*let's leave Oxygen out of this, please, I don't want to start a flame 
war. IOW until oxygen is !broken I'll give it the benefit of the doubt 
as being an exception here.)

>> My personal preference is to fix the kdeui crash (if it's still a
>> problem) so that styles can use features in kdelibs. (I think this would
>> also allow us to kill off kdefx once and for all, by merging it into
>> kdeui.)
> 
> That's fine, as long as it gets enough testing, and not just on < 1 year
> old linux systems. The ld.so bugs we saw during 3.0 development were
> wildly varied on different machines.

All the more reason to get it at least partly working ASAP so we can 
hopefully get it in beta2.

-- 
Matthew
"Please remain calm... I may be mad, but I am a professional."
   -- Mad Scientist