This project is read-only.

Which color/brush key value to use?

Aug 29, 2013 at 11:57 PM
Edited Aug 29, 2013 at 11:58 PM
I am looking at a Colors.xaml file and there are a number of values specified. But they are somewhat generic (BackgroundColor1, BackgroundColor2, etc.)

Is there a guide somewhere that will explain the purpose of the various colors so I be sure to select the appropriate one for a given task.

I would assume that the ones that end with 1 are the defaults. But what else? It doesn't appear that labels and textboxes use the same color values.

Some are well named and really don't need more explanation (CODE.Framework-Application-MenuSelectionColor for example).

So I guess the question is how do I know when to use which BackgroundColor, ThemeColor, ForegroundColor, and HighlightColor)

Aug 30, 2013 at 6:49 PM
On that same note...

I will need some new colors and brushes. I don't mind adding them to my applications themes. But thought I would check to see if there were any plans to add them to the framework and, if so, the naming convention that the FW would be using (so I can use that instead of mine.)

Colors I think I will need:

For validation errors:
Error Foreground
Error Background
Error Indicator (some icon/character associated with the item in question
Error Border

To alert the user that the item is required:
Required Foreground
Required Background
Required Border

Since I use the default colors for view mode, I like to have a way to make it clear that the user is in edit mode or not:
Editable Foreground
Editable Background
Editable Border

And for disabled controls:
Disabled Foreground
Disabled Background
Disabled Border

Unless I hear otherwise, I will just create these in my apps theme.

Sep 5, 2013 at 12:14 AM
Well, that is a tough question to answer :-). Mainly because there are no hard rules. Each theme is free to define whatever colors it needs. And you are free to add your own.

With that said: It makes sense to try to keep the number of colors each theme uses to a minimum. It keeps things sane, and it usually also isn't a bad idea from a design-aesthetics point-of-view. So a few foreground colors (perhaps 3 or 4) and a handful of background colors usually do the trick. They are then used for all kinds of things, from the color of headings, to the color of selected control outlines, and so on. Hence the generic naming.

The list you provide above is actually a good example as to how quickly the list grows drastically and becomes a) hard to manage, and b) you end up with an app that has all kinds of different colors, which usually doesn't look all that good. I would instead use the standard foreground color (foreground color 1) for my editable foreground color and I would use background 1 for the background used by that control. For disabled controls, I would simply use the same color, but either make it slightly transparent, or use our color helpers to darken or lighten the same color. This way, you have just one defined color, but you can use shades of these colors to indicate special meaning. This works well as editable controls are usually black (foreground) and read-only are gray (a "lightened black"). Same if you were to make the foreground blue. Perhaps a lighter or darker blue would be a good indicator for a disabled control. Using this trick, you usually can create good looking apps without needing a lot of graphical talent.

I could however see that a single color resource for errors could be added once we have built-in support for that. Then, that color (probably a shade of red) could be used for error-related things. Themes could then decide to use a certain shade of that color to display control backgrounds for instance. But then again, not all themes may need special colors for errors. Perhaps themes choose to show errors in ways other than with colors (for instance in a theme for the visually impaired). So this would also be something that many themes may need, but not necessarily all of them. Same for an icon. Some themes may want an icon, others perhaps not. This should be left for each theme to decide. We never want to restrict themes too much. Currently, a theme can simply create a theme for individual controls (such as textboxes) and incorporate an error indicator (which they are free to choose). I think we already have icons in our standard icon resources that could act as such icons if needed, but perhaps we could add more when we get to that.