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.
Summary: | Code-Folding: Hovering over code should change the color instead the width | ||
---|---|---|---|
Product: | editor | Reporter: | markiewb |
Component: | Code folding | Assignee: | markiewb |
Status: | NEW --- | ||
Severity: | normal | CC: | sdedic |
Priority: | P3 | ||
Version: | 8.2 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
See Also: | https://netbeans.org/bugzilla/show_bug.cgi?id=104314 | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: |
Patch
Screencast of patch in action using several light and dark editor themes |
Description
markiewb
2016-07-16 16:34:23 UTC
Created attachment 160409 [details]
Patch
Created attachment 160410 [details]
Screencast of patch in action using several light and dark editor themes
@Svata: Can you please review the patch, before I commit it. What do you think? The patch removes the thickening of lines while hovering over a code fold. Instead of that the color is changed. The highlighting color is based on the code fold color, but brighter. If the color cannot be brightened up, then the it gets darkened - f.e. if the original color is white then the resulting color is gray. I also updated the old implementation org.netbeans.editor.CodeFoldingSideBar See the attached screencast and give it a try. If there are no objections, I will integrate it next Wednesday. The reason why the line "thickens" is to emphasize the selected fold. Since the patch makes the color brighter, it gets just in the opposite way - yes, the selected fold changes color, which attracts user's attention, but the contrast lowers which may be confused with dimming unavailable controls. Agree that width change may not be the best way how to emphasize focused element. I've briefly check eclipse and idea, and they both also increase visual weight of the presentation (eclipse: displays outline, idea: changes dotted line to solid ) But - why not do just the opposite: make the default color of folds less contrast, and change to full black on mouse hover ? A question: is there a reason why to compute derived color and not use Fonts & Color settings ? An additional color can be defined and then customized in dark L&Fs. (In reply to Svata Dedic from comment #4) > But - why not do just the opposite: make the default color of folds less > contrast, and change to full black on mouse hover ? Yes, I can propose that. > A question: is there a reason why to compute derived color and not use Fonts > & Color settings ? An additional color can be defined and then customized in > dark L&Fs. I tried that too, but I had to change 3 or 4 additional modules to register the relevant settings. And in the end it did not work for me. So it was too much for me. When I get it done using the F&C-settings, I must also update all default-themes. So what would be the preferred color f.e. for the norway theme. The color is already a dark blue, so darkening the color would makes no sense for me. Brighten it up? An idea: would it be possible to provide _something_ like ColorModel for FontAndColor settings to derive default values for dark theme ? Then [all] colors would be suitably defined and where inappropriate, they could be overriden. (In reply to Svata Dedic from comment #6) > An idea: would it be possible to provide _something_ like ColorModel for > FontAndColor settings to derive default values for dark theme ? Then [all] > colors would be suitably defined and where inappropriate, they could be > overriden. So supporting the Fonts & Color settings is the way. Understood. I will give it another try, when I am in the mood to figure out all the places, where I have to register the font color options. |