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

Maksim Orlovich mo85 at cornell.edu
Wed Jun 27 21:53:15 BST 2007


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.


> 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.

> 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-. Or, to put it
bluntly, asking people who know the technical insanities involved in the
matter one is trying to decide on.

> 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.

>
> 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?

> 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.






More information about the kde-core-devel mailing list