This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Changing NbTheme to use different colors throughout the IDE does not work properly in the text field of the Search Filesystems dialog. Culprit seems to be org.netbeans.modules.search.types.TextCustomizer which hardcodes Color.black and Color.red as the foreground colors for regexpTextField and substringTextField. You should not do this, as it does not work e.g. if someone sets text fields to be white on black! Please use UIManager.getColor for looking up the proper colors. "TextField.foreground" should be used rather than Color.black. For replacing Color.red, you should probably define your own key, e.g. "TextField.errorForeground", and supply a default value (red) if none is set in the UI defaults; themes could then override it sensibly.
How I can set default value for "TextField.errorForeground" from module side? Thanks.
UIManager.getDefaults().put ("TextField.errorForeground", myColor) But don't do this unless the value is null! Theme support allows the default theme file to define this color (or whatever) in UIDefaults. What I would suggest is, somewhere when you initialize the component, do: errorForeground=UIManager.getDefaults().get("TextField.errorForeground"); if (errorForeground == null) { errorForeground = Color.red; } or something like that. It would be bad form for modules to put things in UIDefaults - other modules could clobber the setting, and it would be very hard to track down.
Fixed in main trunk. http://utilities.netbeans.org/servlets/ReadMsg?msgId=375875&listName=cvs Is there some common way how to "publish" module's defined keys?
We're going to need away, if the patches I'm putting together for fixing borders get accepted. So far I've defined (subject to change - I'm still working on it) about 6 - cases like the MiniStatusBar border and the focus indicating border on the maximized MDI window. Given that NbTheme.java seems to be the entry-point for this, probably the best bet is to define some static constants on it - that way the info is all kept in the same place.
"Given that NbTheme.java seems to be the entry-point for this, probably the best bet is to define some static constants on it - that way the info is all kept in the same place." - please do not put any resource names used only in modules into core. No no. If we actually need registration for the defaults (is it really necessary?) there should be some sort of simple declarative registration mechanism using layers (something very fast to parse, since it will have to be done during startup).
BTW don't forget to set target milestones when fixing bugs...
"If we actually need registration for the defaults (is it really necessary?) ..." - I do not need to register default value, but I think the used key should be known for themes.xml writers to know all used keys in NB.
Yes, true, registering it is not hugely useful. My only worry is that it will end up like the various startup line switches for NetBeans, or things you can do with putClientProperty() in the window system, where they are not documented anywhere, and the only way to figure them out is to grep the entire codebase. If all of these are defined as fields on one class, you have a registry of the information. Where it should live, I don't know. "I do not need to register default value, but I think the used key should be known for themes.xml writers to know all used keys in NB." Fine, but will they know? And how will they find out?