[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Mocups of focus hints for panes
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2006-12-05 16:21:38
Message-ID: el46ai$m5j$1 () sea ! gmane ! org
[Download RAW message or body]

(Ok, I'm going to drop core-devel from this part of the thread, as it is 
really more about KATE and usability.)

Anders Lund wrote:
> 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.

If you read the PDF (and possibly the rest of the thread on 
kde-usability and kde-core-devel), the point being made is that NO 
colors at all should be hard-coded by default. IOW KATE's default 
'normal text styles' colors should come from the scheme, rather than 
being hard-coded as they are now. The idea is that the following steps 
should yield a usable color scheme.

1. Install KDE from scratch on a blank system (really, ensure that NO 
settings have been changed from default)
2. Select a non-standard color scheme (one of the 'high contrast' ones 
for an extreme example) or create your own.
3. Start Kate/KWrite (or something using KATE-part)

Right now, it is possible to wind up with (IIRC) black-on-black doing 
this. Certainly the result is not 'readable' right off the bat.


That said, KATE is actually a lot better than some places in that you 
CAN have total control over the colors it uses.

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

That was directed at the usability folks; I agree with you, I don't know 
where this is a problem. I am hoping one of them will either confirm it 
is not, or point out something we have missed.

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

True, the only solution here is to consider on a case-by-case basis if a 
new type should be added. It might be beneficial to provide a non-code 
way to do this (e.g. a file that defines what the default color roles 
are) that could be updated as easily as installing a new highlighter. In 
general, though, this is a matter of not specifying colors in the .xml's 
(IIRC, isn't this already a no-no?).

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

Were you talking about 'normal text styles' colors, or does "all color 
schemes" above mean "all highlighters"?

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

Agreed. (Perl? What about C/C++ and bash? ;-) Er, well, C/C++ uses 
'character', though, but maybe we should differentiate between 
'character' and 'escape'. I also added printf-spec highlighting to my 
own c.xml, so that's yet another one.)

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

There is a 'dsFunction' if that's what you're thinking of? :-)

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

As above, my thought would be to have a separate file defining what the 
'normal styles' are, so that it could be expanded easily. That would 
make it much easier to submit new global styles for consideration.

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

Yes, but the question is 'is it better to force the user to change the 
colors to create distinction, or to use hard-coded values that may not 
match the color scheme'. I think this point needs more discussion before 
a consensus can be reached. Mostly I'm trying to jump in and get the two 
sides talking, since this whole conversation started with a discussion 
that seemed especially devoid of any input from the development side.

-- 
Matthew
You are in a meadow. A huge red dragon stands before you.
 > FIGHT DRAGON
With what? You don't have any weapons.
 > RUN AWAY
You wisely exercise the better part of valor.

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]