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.
Created attachment 94223 [details] screenshot It's very hard to read comments and inactive code now, because they are gray too. Also there is some bug with right margin line.
Ondro, do you have any suggestion please?
Please, have a look at my last comment in bug 172845 Thanks, Vladimir.
I'd also like a reconsideration this grey background. Many SunStudio and dbxtool users still use sccs which unlike cvs or hg leaves unchecked-out files as readonly. For such users the majority of files during debugging will appear with a grey background. And the grey background is visually very jarring.
Created attachment 96306 [details] comparison of suggested/old color The point of this change was to be consistent with other contexts in which the gray background is used to indicate read-only sections. And especially the note about readability of comments of course applies to these guarded sections as well, i.e. reverting back to white background would not solve the problem. So, let's try to change the color to somewhat brighter (92% gray, 8% black). There should be less contrast and it should be less disturbing for ivan and Vladimir (see the attached image for comparison). If this would not help, we can then revert the setting for CND files (*) but let's try to improve the color first, especially since readability of comments may be a concern for all files. (*) AFAIK, both complains were from CND land, no Java users' complains as of yet.
Ondrej. I think not only bg color is the problem. a mix of read-only&&white colors inside editor is issues as well. Can you create example with your new color *and* all other background (bg) white places changed to new color: - bg of code folding bar - bg of editor below the code => in that case it might looks more attractive... Thanks! Vladimir. P.S. I'm thinking about old settings for C/C++/Fortran files as well. I hope this bg color is not the same as used in protected section of editor, but has another "key" which we can customize. I don't want to change bg for guarded blocks
It's hard for me to judge the color from your sceenshot on my laptop. Will have to wait til tomorrow. Validmir has a point. I remember an article a long time ago about how the IBM PC's monitor was designed. The HIE's talked abut how the dark color of the monitor is surrounded by a less darker color of it's inner frame and then a light beige color of the surrounding frame. They reasoned it helps the eye adjust as it's field of view traverses into and out of the monitor. I think the same principle applies here ... the white stripe of the glyph gutter and the still white no-text area at the bottom create for very sharp contrast. Sharp contrast sends a signal to the brain: "pay attention, there's something here". If the brain pays attention and finds nothing interesting there it gets "frustrated" and then "tired". Another consideration is for when things get animated. "animated" you say? That happens in debugging as you quickly step through various functions and files. If some files are ronly and some editable as you step you'll get flashed with, in the worst case, large chunks of screen turning dark and light. I know the number and situations where people will get impacted will be small for for those who are impacted it will not be insignificant. I'm polling SunStudio people to decide if we indeed believe that many customers still use sccs (Or some other VCS that keeps unchecked-out files as readonly). It seems unlikley that such VCS will be used under NB because of lack of support but even then ... I believe there will be a class of people that will be using the IDE as a debugger, or using dbxtool or dlight on really old code. It's that class I'm concerned about. Re java users ... it's not the language, it's version control practices I think that have a bearing on this.
(In reply to comment #6) > > Re java users ... it's not the language, it's version control > practices I think that have a bearing on this. Open "String" Java class and you will see the same for Java => any sources provided for jars in src.zip would have such coloring as well.
Vladimir: --------- > Can you create example with your new color *and* all other background (bg) > white places changed to new color Now I see what you mean. Such image is attached. Does it look better to you? > I hope this bg color is not the same as used in protected section of > editor, but has another "key" which we can customize. It is. The goal of changing the background to of non-editable files is to be consistent in the way we communicate: "this is something you can not change", which applies to both guarded sections as well as read-only files. This may sound odd to you as someone very experienced with the IDE, but such small (in)consistencies in UI in their sum really do affect learning curve of the tool. Also, if someone has a bad sight and they want to enhance contrast between background in non-editable text and e.g. comments in such text, they should be able to do so at once, not having to search for multiple keys. > Open "String" Java class and you will see the same for Java => any sources > provided for jars in src.zip would have such coloring as well. Yes, you're right. I did not mean it would be CND specific, I was only referring to that AFAIK, we've many more Java developers then C++ developers, but no complains yet from Java pple yet. Which means they either do not come across read only files often (debugging "String" is not a common use-case, right?) or they do not mind the coloring. Ivan: ----- > Will have to wait til tomorrow. Will not work. The change has been "photoshoped", so that I could quickly play around with various shades of gray and see immediately what could be a good compromise, it's not done in codebase. > think the same principle applies here ... the white stripe of the glyph > gutter and the still white no-text area at the bottom create for very > sharp contrast. Agree with most of what you wrote. See the attached image. If you had a link to the article you mentioned, I'd appreciate it. > I believe there will be a class of people that will be using the IDE > as a debugger, or using dbxtool or dlight on really old code. If it's a minority, using an unsupported versioning system, they can always customize the experience. Let's try to focus on making this as good as possible for the 95% (just a guess) using supported versioning systems and the others can (and most likely will) tune the IDE to serve them well enough. Thanks guys for constructive criticism and discussion. Also changing to P3, as this is not "critical usability issue" as defined in bug usability guidelines.
(In reply to comment #8) > Vladimir: > --------- > > Can you create example with your new color *and* all other background (bg) > > white places changed to new color > > Now I see what you mean. Such image is attached. Does it look better to you? Where is it attached? > > > I hope this bg color is not the same as used in protected section of > > editor, but has another "key" which we can customize. > > It is. The goal of changing the background to of non-editable files is to be > consistent in the way we communicate: "this is something you can not change", > which applies to both guarded sections as well as read-only files. This may > sound odd to you as someone very experienced with the IDE, but such small > (in)consistencies in UI in their sum really do affect learning curve of the > tool. Also, if someone has a bad sight and they want to enhance contrast > between background in non-editable text and e.g. comments in such text, they > should be able to do so at once, not having to search for multiple keys. I agree with your point. And exactly for such customization there is "Inherit" property of Font&Colors. So, base "key" could be "read only section" derived would be "read only file" -> inherits "read only section" => you can change last or only base one
Created attachment 96427 [details] attachment - without white margins Attachment I previously mentioned but forgot to include.
this is much better :-)
Yes, the new image is definitely better. As for the article ... heh heh It was published in BYTE magazine circa 1981.
Vito, is my last attachment "implementable"? If so, could we go with using the background color for the entire file as shown in the first step? Maybe even making the color brighter will not be needed ... we'll see.
(In reply to comment #13) > Vito, > > is my last attachment "implementable"? Umm, well, pretty much everything is implementable :-). However, it's going to be much harder than what we have now. We will have to update all sidebars to either use the color or become transparent and set the background color of the extended editor component...
Please add a setting within the editor to control the read-only color. We review many read-only files and it defeats the purpose of customizing the color set of the editor if everything looks and acts different, such as variable highlighting, line selecting and etc, when it's a read-only file. Is it that uncommon to review read-only files, such as in the case of debugging other related writable-files?
I think this "feature" went astray because it didn't make the fine distinction between "shouldn't be changed" and "can't be changed". The grey background got it's start as the background of machine generated code most notably code inserted and generated by the GUI builder. Such code might be in a _writable_ file but it "shouldn't be changed". If it ends up in a readonly file then the current scheme will smear everything grey and you won't be able to spot the "shouldn't be changed" code. OTOH, that a file is readonly has to do with "can't be changed". Can't because it needs to be checked out, or NFS re-mounted with ro privileges, or is owned by someone else and is just being browsed. Some cases of "machine generated" code, like the decompilation into source for the purpose of the debugger, also falls in this category INO. That is not to say that there should be no hint that a file isn't editable. But the current solution is too drastic and causes ambiguity between what "shouldn't be changed" and what "can't be changed".
I'm putting "feature" back as ui usability "defect", not "enhancement" Any read-only file has enough hints about it's read only state with italic title, there is no need to change background
meeks: Tools->Options->Fonts&Colors->Highlighting->ReadonlyFiles Vladimir: Is the current state satisfactory or shall we remove the grey background for RO files? I mark the issue as fixed please reopen if necessary. Thanks.
Created attachment 149820 [details] Bug 180826 - Gray background in read-only files This shows how difficult it is to read the Debugger -> Watches -> Values I have followed the instructions and used : Tools->Options->Fonts&Colors->Highlighting->ReadonlyFiles I set the background and foreground colors to red, blue, green, etc. but this has not helped. The light gray foreground color of the Debugger -> Watches -> Values are extremely hard to read under most lighting conditions. Can someone please help with this issue. I have spent hours trying to find a solution. I am using NetBeans 8.0 on the latest version of OS X.
Created attachment 149821 [details] Shows display contrast between Watches and Variables
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