[kde-doc-english] KDE/kdebase/workspace/doc/kcontrol/colors

[Arturo Silva]

hi.  ^^
Seem this is already being taken care of and seems to have resulted in
some pretty possitive contributions.  So I'll just supply residual
comments to some things, as I'm in complete agreement with just about
everything else....  ^^


>> Good point. I'm not very fond of "custom scheme" however, but I changed
>> this line to "the active color scheme", a term which is explained
>> above¹. Do you think that is sufficient?

More than sufficient!  ^__^


>> That's reasonable. Changed as follows:

Perfect!


>> Yes, the color role name is being used as a noun. I'm basically in
>> agreement with everything you said. Maybe some other method, such as
>> putting all role names in quotes, or making them bold, or some such,
>> would be better?

I would say more towards the bolding idea, since it provides a visual
reference to the reader that Active Titlebar is a full reference to
the prior section. On the other hand, this would beg the question on
whether additional elements in the help docs should be bolded as well,
in which case this could be the proverbial can of worms.

In all honesty, it's too minor a point (I'd rather we use the time to
write new documentation that doesn't exist) so maybe we can leave as
is. ^^b


>> I could do that, but it would have four colors ;-). (At one point, there
>> was thought of having rather more WM roles, but so far nothing has
>> happened there.)
>> The problem is that "common" here means more along the lines of
>> "popular", not "shared"... an ambiguity in the English language. Any
>> ideas on a better (less ambiguous) word?

LOL! Yeah, I imagined it would be too tiny a color set.  :P

As for suggestions, the UI adjustment would pretty much take care of
this to an extent (if it is feasible for implementation).  As for
alternative suggestions,... besides "General", can't really think of
anything else that wouldn't sound out of place.  ^^;



>> Hmm... that might work. On the down side, it is harder to "switch
>> modes"... but it might make things a bit less strange. Anyone else want
>> to weigh in?
>> (There are, in fact, some other advantages from a technical standpoint,
>> but nothing the user would notice.)

As long as I'm not a software developer myself, I generally try to
refrain from suggesting things like this since I don't have a full
comprehension of how much work this will entail.  Something that
sounds easy to implement may be anything but.  :(

Still, it was worth the suggestion I feel, and more so if you also
point out there may also be technical advantages to this.

Hopefully as I get exposed to more documentation and artwork, I might
be able to offer similar UI "tweaks" that are at least a bit more
surgical and doable than broad wish list items.


>> Policy is simple: NO string change in branch, not even a one char typo
>> fix is allowed (there are really good reasons for that).

I guess in time I'll know what this means.  ^__^;


Thanks again for reviewing my feedback!


--Arturo "C-quel" Silva