>> On my own, I tried to use the "strikethrough" font effect which I can set
>> in the color options, but it did not work well with selection. In particular,
>> if I set the unused text to Red, and a red strikethrough, selecting this text
>> would change the background and front colors to the OS-dependent selection
>> colors, but strikethrough remained in red.
> At the moment each effect has to have its color specified explicitly. Perhaps
> we could tweak the DrawEngine to use a foreground color for drawing effects
> that do not specify their own color. In your example the 'strikethrough'
> effect would normally be red, but white when selected. Would that help?
Yes - when text is selected, the normal foreground and background colors are
suppressed in favor of the selection foreground and background. I think all font
effects (strikethroughs, underlines, wavy underlines) should all switch to the
selection foreground as well.
And yes, as we discussed elsewhere, I think font effects should automatically
default to the foreground color; if I have specified red for unused and I choose
"strikethrough", it should just use red for the strikethrough color too (unless
I specify it to be something else. I don't think that's useful for strikethrough
- it might be for wavy underlines but I actually doubt it. This may be a bit of
over engineering on our part.)
I'm just an interested observer but i suggest that the default background color of the editor be changed to the default
textcomponent SystemColor. If the High contrast mode is activated the background of the Editor continues white (and the
foreground still black), when by default it should follow the system. Also in the options fonts & colors tab there is no
way to choose a systemcolor (even if you try to choose a "custom" color).
Thanks for the comments. The problem you describe is a little bit unrelated to this issue, but anyway it is a problem.
The color chooser should definitely support choosing system colors. I would be reluctant to use system colors
automatically for the default editor bg/fg colors. The reason is that each theme (profile) defines more than just
default bg/fg and all the colors in a theme are chosen to look reasonably good as a whole. If you, for example, swapped
bg/fg, but left the other colors in the theme unchanged the theme could become unusable (with invisible or hard to read
*** Bug 185288 has been marked as a duplicate of this bug. ***
I think there are two issues here:
1) Effects should switch colors on selection just like text does.
2) Add the ability to specify "Same as Foreground" as effect color.
For example I'd like to use 2) for the "Deprecated Element" category, so that the strikethrough color follows the syntax highlighting there. But of course we don't want this for all categories, e.g. the Error waveline should remain red regardless of the text color. So IMO there should be a "Same as Foreground" color option for the effect color, just as other settings have an "Inherited" option.
@vstejskal: If you agree about the separate issues 1) and 2), it probably makes sense to reopen issue 185288.
(In reply to comment #4)
> @vstejskal: If you agree about the separate issues 1) and 2), it probably makes
> sense to reopen issue 185288.
Yes, I agree that these are separate issues, but they are so closely related that it IMO makes only little sense to create a new separate issue for #1. Also, I think that fixing #2 will effectively fix #1 as well. Well, in fact we might need three distinct values for an effect:
a. a specific color
b. 'same as foreground'
c. 'same as inherited foreground'
The difference between b and c is that in b the effect has a specific color assigned and it is the same as the foreground color of the coloring, which the effect is defined for. In c the effect has no specific color assigned, but it will use whatever color is the actual foreground color defined (by other colorings) for the area where the effect applies.
In practice I think it will be enough to implement c and call it simply 'same as foreground'. If the effect's coloring defines a foreground color and (for a specific area) it is going to be the active foreground color then the effect will be drawn with that color. If the effect's coloring does not define a foreground color or this color is overriden by other coloring (eg. text selection) then the effect will be drawn with the other foreground color.
I'm not sure if I explained this sufficiently, but if we implement c we will get both #1 and #2 issues fixed. And that's my preferred solution.
Not sure I understand the difference between b and c. I'd certainly like the color(s) of the syntax-highlighted text to apply. If that is c, I'm fine.
I wouldn't use the word "inherited" though, because elsewhere "inherited" refers to the highlighting category hierarchy.
(Strangely, there is no "Inherited" value for "Effects", although "None" appears to have the effect of actually inheriting the setting of the parent category.)
(In reply to comment #6)
> color(s) of the syntax-highlighted text to apply. If that is c, I'm fine.
Yes, that's it.
> I wouldn't use the word "inherited" though, because elsewhere "inherited"
> refers to the highlighting category hierarchy.
I agree, I'll just call it 'Same as Foreground' as you suggested.
One particular use case, by the way, is URLs in Javadoc commments (or elsewhere), which currently have a blue underline effect by default, instead of matching the color of the URL's text.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.
Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss
Still relevant in current dev build.