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.

Bug 180826 - Gray background in read-only files
Summary: Gray background in read-only files
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Painting & Printing (show other bugs)
Version: 8.0
Hardware: Macintosh Mac OS X
: P3 normal with 2 votes (vote)
Assignee: Miloslav Metelka
URL:
Keywords: UI, USABILITY
Depends on:
Blocks:
 
Reported: 2010-02-17 05:05 UTC by nnnnnk
Modified: 2016-07-07 07:28 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
screenshot (99.93 KB, image/png)
2010-02-17 05:05 UTC, nnnnnk
Details
comparison of suggested/old color (793.54 KB, image/png)
2010-03-30 09:36 UTC, Ondrej Langr
Details
attachment - without white margins (236.47 KB, image/png)
2010-03-31 12:47 UTC, Ondrej Langr
Details
Bug 180826 - Gray background in read-only files (89.63 KB, image/png)
2014-10-09 19:38 UTC, mbs400
Details
Shows display contrast between Watches and Variables (102.14 KB, image/png)
2014-10-09 19:41 UTC, mbs400
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nnnnnk 2010-02-17 05:05:51 UTC
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.
Comment 1 Vitezslav Stejskal 2010-02-18 06:20:06 UTC
Ondro, do you have any suggestion please?
Comment 2 Vladimir Voskresensky 2010-02-18 07:02:17 UTC
Please, have a look at my last comment in bug 172845

Thanks,
Vladimir.
Comment 3 ivan 2010-03-29 21:48:09 UTC
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.
Comment 4 Ondrej Langr 2010-03-30 09:36:25 UTC
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.
Comment 5 Vladimir Voskresensky 2010-03-30 09:45:49 UTC
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
Comment 6 ivan 2010-03-30 18:55:18 UTC
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.
Comment 7 Vladimir Voskresensky 2010-03-31 08:16:13 UTC
(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.
Comment 8 Ondrej Langr 2010-03-31 08:57:57 UTC
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.
Comment 9 Vladimir Voskresensky 2010-03-31 09:59:57 UTC
(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
Comment 10 Ondrej Langr 2010-03-31 12:47:14 UTC
Created attachment 96427 [details]
attachment - without white margins

Attachment I previously mentioned but forgot to include.
Comment 11 Vladimir Voskresensky 2010-03-31 13:10:20 UTC
this is much better :-)
Comment 12 ivan 2010-04-02 02:29:50 UTC
Yes, the new image is definitely better.

As for the article ... heh heh It was published in BYTE magazine
circa 1981.
Comment 13 Ondrej Langr 2010-04-06 12:30:42 UTC
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.
Comment 14 Vitezslav Stejskal 2010-04-07 11:05:00 UTC
(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...
Comment 15 meeks 2010-07-15 18:50:28 UTC
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?
Comment 16 ivan 2010-07-15 20:54:50 UTC
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".
Comment 17 Vladimir Voskresensky 2010-07-16 06:22:14 UTC
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
Comment 18 Miloslav Metelka 2011-08-11 15:46:19 UTC
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.
Comment 19 mbs400 2014-10-09 19:38:26 UTC
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.
Comment 20 mbs400 2014-10-09 19:41:18 UTC
Created attachment 149821 [details]
Shows display contrast between Watches and Variables
Comment 21 Martin Balin 2016-07-07 07:28:41 UTC
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