Mocups of focus hints for panes

[Matthew Woehlke]

(Please mind the multiple CC'd lists when replying.

I assume some/all of the core KATE developers have seen this already, 
but I've been on kwrite-devel for some time and didn't see this go by, 
so I'm taking the liberty of letting other kwrite-devel readers that 
don't follow -usability see what we are saying about their editor.)

Olaf Schmidt wrote:
> 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.
> [snip]
> You can find an outdated version of the document here:
> http://amen-online.de/~olafschmidt/colors/colors.pdf

If you'll pardon me (again) for butting in, I'd like to offer specific 
comments on KATE, that being rather near and dear to my heart. :-)

(All following quotations are from the aforementioned PDF)
> Currently, the Kate colors are partly controlled by application color
>  schemes, partly from other application color settings, and partly by
> the syntax highlighting schemes.

Right. This needs to be fixed.

> In KDE4, all colors used by Kate should be included in an application
> specific color scheme.

Actually, this is already the case in KDE3, unless I am missing something.

>  Syntax highlighting schemes needing additional colors should not be
> allowed to define them. Instead Kate should either use the new
> function in kdelibs to find an additional color that fits the current
> color scheme, or combine existing color roles with a different font
> style.

Hmm, as a writer of syntax highlighting files, I have a few comments. 
Highlighters SHOULD NOT SPECIFY COLORS, EVER (and should avoid 
specifying attributes, although this is a much looser restriction). If 
the built-in styles are insufficient, then maybe the built-in types need 
to be expanded. Otherwise it is better to re-use an already-used type 
and force the user to supply distinction.

-- 
Matthew
"Braaaaaaaaiins!" -- Zombies