Mocups of focus hints for panes

[Matthew Woehlke]

(Re-CC'ing kde-usability; please keep them in the loop!)

Olaf Schmidt wrote:
> Nice work.

Thanks! I'm not done, of course. If response remains positive, I will 
probably submit a patch/new version of plastik so that there is a head 
start here.

> I totally agree with adding new colours for the focus, but I believe those 
> should be available in the general colour configuration and for all styles.

Do you mean "they should be in Apparence->Colors"? Isn't that what I 
said? :-) (Hmm, I guess it isn't; not in the previous post, at least, 
although I seem to recall saying it elsewhere.) At any rate, what I 
meant by "already" was exactly what you are saying; it seems to me also 
that there should be a global way of setting these colors, that would 
track with color schemes. What we have right now, you have to change it 
at the style level if you change your global color scheme. (Hmm, I 
wonder if it is possible/reasonable to add style-specific 'hooks' to 
global color schemes?)

Or in fewer words, "Yes, I totally agree with you." :-) Working with 
plastik just gives the advantage that I can change them for 
testing/proof of concept without having to go to the effort of doing 
/this/ The Right Way as well.

> In the HCI working group, we already discussed adding additional colour roles 
> to kcontrol. We have worked out a suggestion that serves the needs of 
> artwork, usability and accessibility. For example, extending the colour 
> schemes makes it possible to create colour schemes for users with visually 
> users. Currently those colour schemes break in most KDE applications because 
> of custom colours (e.g. KMail, Konqueror, Kate, Konversation, Kopete, ...)

No objections; see above comments and also see:
http://lists.kde.org/?l=kde-core-devel&m=116496380204005&w=2
and
http://article.gmane.org/gmane.comp.kde.devel.kdevelop/16849
(Apologies that I can't give a kde archive link for that; kdevelop.org 
seems to be down and I don't see the list on KDE's main list of lists.)

I just submitted a patch to KDevelop w.r.t. this exact issue. The 
(second) link above is the top of the thread; the patch doesn't seem to 
have posted yet.

> You can find an outdated version of the document here:
> http://amen-online.de/~olafschmidt/colors/colors.pdf
> All the mockups for new or changed widgets have been much changed in the 
> meantime in cooperation with Ellen, and I will soon update that document 
> accordingly,

Please tell me when it is updated, I would be very interested in seeing 
what your ideas are (since I seem to have volunteered to help with an 
actual, sane-from-a-developer's-perspective implementation :-)).

> The complete list of suggested colour roles pairs (each with foreground and 
> background colour) for kcontrol is:
> [snip]
> colour 2 (e.g. Link, Unread)
> colour 3 (e.g. Link, Read)

Note that these are already in Qt, although if you implement 
per-background versions (you should; see below), then KDE should stop 
using them and use custom versions. And the numbers should start from 
'0' (btw, where did '1' go?).

> colour 4 (e.g. New)
> colour 5 (e.g. Error or Warning)

Eep, no. Error and Warning need to be /separate/ entries. Combining them 
is BAD BAD BAD in development.

> colour 6 (e.g. Trusted)
> colour 7 (e.g. Encrypted)
> colour 8 (e.g. Comment or Alternate List Background)

Um, no, comment and alternate list background need to be different. It 
is common (or at least I would guess it is) for alternate list 
background to be VERY similar to 'standard', which makes for a bad color 
to use as a foreground color. Since we already have an 'alt list' I 
would make this just comment and leave the current 'alt list' alone.

(On to the general reply)

That will take care of a lot of KDevelop (as mentioned above). Actually 
my patch makes do with just link[visited] so that much is OK, but better 
defined color roles will help.

> The idea is that the numbered colours can be used by applications that need 
> more colours than usual (e.g. KMail, Konqueror, Kate, Konversation, 
> Kopete...). They can be mixed with each other and with standard / window / 
> button / tool tip.

If you want them to be mixed with each other, you need to VERY clearly 
define which ones may be mixed and in what combinations, otherwise you 
will most likely have someone pick two mixed colors that mix to be 
indistinguishable from the background. You can rely on things like 50% 
'highlight and highlight text' producing a legible color. But you can't 
make assumptions like 'window text will be legible against highlight'.

On that note, you also need to specify what background each may be shown 
against ('standard' is assumed, 'button' and 'window' are implied). To 
Do Things Right, there really should be four versions of each color, for 
display against button, window, standard, and highlight. (Note that KATE 
already does this; it just only has two backgrounds it needs to deal 
with.) You might even throw 'alt list' in there, but I'm willing to be 
mean to anyone using an 'alt list' color that is wildly different from 
their 'standard' :-).

My patch already violates the above by making the dubious assumption 
that 'link' and 'link visited' are legible against 'button'. As per 
above, this probably happens in practice anyway, but it is really not an 
ideal situation.

-- 
Matthew
"Braaaaaaaaiins!" -- Zombies