I’m working on changing the colors of an app (CapitalBe) to use the current system colors instead of hard-coded color values.
I’ve used B_PANEL_BACKGROUND_COLOR for view backgrounds, but what other colors are available? Is there a list available somewhere?
The BeBook lists some of the main ones. You can also look at the InterfaceDefs.h header file for the full list of color_which constants.
Thanks, the list in InterfaceDefs.h was very helpful. Combined with the color tinting listed in the same file I’ve got a lot of options to use!
If you want to avoid problems later, try to always use a text colour on the background associated. For example, if you use panel_background_color then text should be of panel_text_color. If the user is tweaking colours, using the right combination will always keep you safe. Said like that, it sounds obvious but, there are many places where it is not the case i.e font previews in Appearance (document_text_color on panel_background_colour) and Web+ (black text on panel_background colour).
Hi, after reading this post and realizing they actually are not documented I opened a change request to document them. It’s not completely done but maybe it helps.
https://review.haiku-os.org/c/haiku/+/7656?tab=comments
regards
Could you please complete many of the other things that are not currently documented in the Haiku Book?
If you have specific issues you can open a ticket on https://dev.haiku-os.org . Otherwise just completing it makes no sense, I‘ll usually only make documentation improvements if I notice they are missing, or someone else does and tells me.
Otherwise I‘d have no time for anything but documentation : )
Having a complete and updated work in one place is not anything “non sense”. It helps native apps developers to get the information of the component they need to know to build their apps, avoiding them the waste of time of having to dig into the system source code and trying to figure out what a thing does.
If you don’t have time, it’s OK. No one is forcing you to update the docs. But if you or any other dev does it, it would be great. But otherwise, if no one wants to make the documentation complete, then later do not whine about how no new devs join the ecosystem or how almost no native apps are being built.
Asking someone to just complete it makes no dense is what I said, not that a complete doc makes no sense.
If you want to make sure it is complete above all else that would require someone to painstakingly compare every doc file to the code, which I don‘t think makes sense in the time used vs reward department, hence my request to file a ticket if you find anything.
Should I open one per undocumented component or one for all? Also for the private components such as BColumnListView?
I’m not really sure what these tickets would be helpful for. We know the documentation is far from complete and at this point there’s no need to waste hours opening a hundred tickets about it?
Here’s a glimpse of how the app is coming together with the new colors, thanks for helping with documentation and resources.
On a site note, what’s the difference between SetHighUIColor() and SetLowUIColor()? The documentation says it sets the high and low colors of a view, but what are those?
Having one or two tickets that list what would need to be done would help keep track and prioritize.
I know the documentation is incomplete, but other than comparing manually there is mo telling what exactly is missing. If you have some stuff you know you can ofcourse fix that, but that does not help other devs who want to do this.
These colors for example suprised me, I assumed they were documented already. : )
From the BeBook:
The high and low colors roughly match what other systems call the fore and back, or foreground and background, colors. However, neither color truly represents the color of the foreground or background. The terminology high and low is meant to keep the sense of two opposing colors and to match how they’re defined in a pattern.
Most drawing function can use thesetwo colors usiig the B_SOLID_HIGH and B_SOLID_LOW constants, or can use a pattern which uses both (for example to draw every other pixel in alternating colors). This is rarely used today, it was common on 256-colr or less user interfaces. But it can still be used to fill a shape with hashmark patterns if you want to do such a thing. Or as a convenient way to have two “active” colors, and, for example, fill a shape with one, and draw its outline with the other.
I’ve run into a small challenge with tinting some of the colors, if I can explain this properly…
When using a color like B_LIST_ITEM_TEXT_COLOR (which is either black or white) in combination with a tint constant like B_DISABLED_LABEL_TINT or B_DISABLED_MARK_TINT, it only works for half of the color specter. In “dark mode”, B_DISABLED_MARK_TINT won’t do anything, and vice versa in “light mode” with B_DISABLED_LABEL_TINT.
I can of course use grey, or another constant, but I’m curious if there is a clever workaround for this, by lightening a color if it is black and darkening a color if it is white? E.g. to show a string as muted or disabled.
Since these are defines for specific colors and do not respect dark mode as such you will have to do this yourself.
I‘ve added some new api calls to rgb_color recently you can use for this.
Contrast(), IsDark() and IsLight()
The commit introducing it gives some examples.
https://cgit.haiku-os.org/haiku/commit/?id=9931e8eeeebf00f45574b8f2e3257ec56d33860f
from tracker Utillities.cpp
ReadOnlyTint(rgb_color base)
{
// darken tint if read-only (or lighten if dark)
return base.IsLight() ? B_DARKEN_1_TINT : 0.85;
}
If you are developing for beta4 instead of the nightlies you can use perceptual_brightness instead.