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
