In a default LO install, the Application Colors dialog (Tools - Options - Application colors) sets all colors to "Automatic". The problem arises when you try to figure out what color "Automatic" really means using a macro. Consider the following Python macro: def get_color(args=None): bas = CreateScriptService("Basic") ctx = uno.getComponentContext() smgr = ctx.getServiceManager() config_provider = smgr.createInstanceWithContext("com.sun.star.configuration.ConfigurationProvider", ctx) # Configuration access to point to the root of the ColorScheme node color_node = "/org.openoffice.Office.UI/ColorScheme" node_path = [PropertyValue(Name='nodepath', Value=color_node)] config_access = config_provider.createInstanceWithArguments("com.sun.star.configuration.ConfigurationAccess", node_path) current_scheme_name = config_access.CurrentColorScheme current_scheme = config_access.ColorSchemes.getByName(current_scheme_name) # Get the DocColor color color_node = current_scheme.getByName("DocColor") bas.MsgBox(f"Theme name: {current_scheme_name}\nDocColor: {color_node.Color}") The macro above should get the color used for "DocColor" (Document Background; it could be any other valid color in UI.xcs). If you run this using the "Automatic" color, the macro will return "None" for the color instead of the actual color being used. Hence, it is impossible to know what color is actually being applied. However, if you change the color from "Automatic" to some actual color value, the number of the color will be displayed as expected. This is bad if you're trying to create a macro or extension that needs to check what color is being actually used in the user's system. If the user is on the default color scheme, it is impossible to know any color via scripts because they're all "Automatic". What I would to propose is the development of a simple API that returns the same value as ColorConfig::GetDefaultColor. Code pointer: /core/svtools/source/config/colorcfg.cxx Maybe this could simply be implemented as a service.
@Heiko, @Sahil what are your opinions on this?
Would be wrong in the code too if you access the color scheme. Typically it is svtools::*COLOR or ColorConfig::GetColorValue() being converted to the actual value. Meaning, IMO we have too many places where colors are read from (and set) and should not introduce another.
I don't think this is a common use case for the default color scheme for which we should change the code for color. When some theme is applied, the color name/hash is shown instead of Automatic. Some people might be using "Automatic" as an indicator for the colors that they didn't change.
See also bug 159541
The use-case that I'm proposing is this: suppose you're writing an extension and in order to blend its dialog better into the user's system you would like to know what exact "DocColor" and "FontColor" they are using. The problem is that when the user sets it colors to "Automatic" it becomes impossible to detect what the actual color is. What I'm proposing is to develop some way where macro developers can get the actual UI colors to theme their extensions. Something similar to the next code (in Basic): oColorGetter = CreateUnoService("com.sun.star.awt.UIColors") aColor = oColorGetter.getColor("DocColor") The proposed service above would return only actual colors. (In reply to Sahil Gautam from comment #3) > Some people might be using "Automatic" as an indicator for the colors that > they didn't change. If the person needs to know whether a color is "Automatic" or not, the macro I showed in comment #0 will allow to do it. And the proposed new API won't change that. Also, I'm not proposing a color setter, because this can already be done with the existing ConfigurationUpdateAccess service. I am only proposing a color getter.
So the color picker dropdown for the various buttons under tools > options > application colors has a button at the end [Customize color], which opens a color customization dialog. Now, for the Automatic colors, even if the color is something other than white, the color customization dialog shows 255, 255, 255. For the changed colors it shows the actual rgb hex value. I propose that we should have the correct hex value for the automatic color in the color customization dialog. That way if someone wants to check what color it is, they can just open the [customize color] dialog.
(In reply to Sahil Gautam from comment #6) > So the color picker dropdown for the various buttons under tools > options > > application colors has a button at the end [Customize color], which opens a > color customization dialog. I know that.... the problem is that you cannot pick this color with a macro. > Now, for the Automatic colors, even if the color is something other than > white, the color customization dialog shows 255, 255, 255. For the changed > colors it shows the actual rgb hex value. I propose that we should have the > correct hex value for the automatic color in the color customization dialog. > That way if someone wants to check what color it is, they can just open the > [customize color] dialog. This would not make it possible to pick the color via macro either.
Hi, As an LibO extension developper and maintainer, I was planning to offer dark mode for one of these extensions. But I'm facing the exact same limitation as reported by Rafael Lima: impossible to determine the current LibO appearance if set as "automatic" (probably the most common case). Whatever could be the best solution here, it will ease the work of extending LibO.