Mocups of focus hints for panes

[Anders Lund]

On Tuesday 05 December 2006 01:53, Matthew Woehlke wrote:
> 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.

I'm not sure I understand this.

Kate pr. default inherits some colors -- selection, background, text -- from 
the KDE color scheme, but they can all be changed. The default scheme is 
compatible with the default KDE color scheme, with white background, black 
text and blue selection.

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

You didn't miss anything, all colors in the editor --KatePart-- can be changed 
in the scheme configuration.

The rest of the colors of course are using the KDE color scheme, apart from 
specialities like the document list item backgrounds, which is also designed 
to be compatible with the default KDE color scheme and can be configured by 
the user.

These colors can't be in the kate color schemes, which are provided by the 
editor component, not by the Kate application.

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

This is difficult, as we can't possibly know the number of colors required or 
the meaning of them.

What we can do is ensure that all color schemes use the default colors where 
applicable, and that additional colors defaults to be usable in the default 
KDE color scheme.

Most highlight files does fill this request, but there are a few that does 
not, notacibly PHP and Scheme ;)

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

I agree to the idea of expanding the built-in attributes where it makes sense. 
And we do so when we see the need, for example we added a ALERT attribute 
when we made highlighting of strings like TODE, FIXME etc. common.

I personally believe we should also provide an additional string highlight, 
because many programming languages have different types of strings (perl with 
its single- and double-quoted strings is a good example, and the perl 
highlight indeed specifies an additional attribute for this purpose).

And I'm not sure if we added a attribute for 'command' or 'function' (and too 
lazy to look that up just now).

Another common need for attributes comes from regular expressions, which 
currently just uses other attributes. Regular expressions should have 
attributes for 'regex-string', 'regex-class' and 'regex-assertion'.

I would love to add these, if the kate team agrees.

If you can think of more needs not covered by the existing set of attributes, 
please let us know!

That said, there will still be cases where the available attributes does not 
cover the needs, and in such cases again a highlight does need to define 
extra ones.

-anders
-- 
www: http://www.alweb.dk
jabber: anderslund at jabber.dk