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.
On my brand-new (Ubuntu, Samsung SyncMaster 245BW display) system, it's very annoying to read the debugger values. They're a more faded, washed-out shade of grey than when I was running in Windows (on a different monitor). I'd call the current debugger color scheme on this monitor usable, but just barely. I'll include a screenshot (a photo, actually)
Created attachment 56754 [details] photo of screen
this bothers me also. I don't understand why the values are greyed out in the first place. Is it to indicate they're not editable? Please use another mean to indicate that, if you feel it's necessary. In any event, there are plenty of things in the IDE and on the desktop in general that are not editable. It would be silly if they were all greyed out, wouldn't it?
This is general debugger problem, reassigning...
This is general TTV problem, reassigning...
Please follow http://qa.netbeans.org/bugzilla/bug_priority_guidelines.html
According to the guideliness, it's a P2. Text that's almost invisible for an important function meets the criteria: # usability Critical usability problem
i don't think this is a TTV issue. the 'washed out' text is for read-only values. so debugger can either set a different color for read-only values or use writable properties instead. reassigning back to debugger
I do not see any reason why debugger should shuffle with colors, we just implement PropertySupport.canWrite() The component, which displays the property is responsible for the correct visible display. The fact that the value should not be modified does not mean that it should not be readable. Under the debugger I've found that TTV is likely not involved, it's a business of the property sheet: org.netbeans.modules.viewmodel.TreeModelNode$MyProperty.canWrite(TreeModelNode.java:892) org.openide.explorer.propertysheet.RendererFactory.getRenderer(RendererFactory.java:219) org.openide.explorer.propertysheet.RendererPropertyDisplayer.getRenderer(RendererPropertyDisplayer.java:293) org.openide.explorer.propertysheet.RendererPropertyDisplayer.paintComponent(RendererPropertyDisplayer.java:272) javax.swing.JComponent.paint(JComponent.java:1027) javax.swing.JComponent.paintChildren(JComponent.java:864) javax.swing.JComponent.paint(JComponent.java:1036) org.openide.explorer.propertysheet.PropertyPanel.paint(PropertyPanel.java:1155) org.openide.explorer.view.TableSheetCell$FocusedPropertyPanel.paint(TableSheetCell.java:747) javax.swing.CellRendererPane.paintComponent(CellRendererPane.java:134) javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:2073) javax.swing.plaf.basic.BasicTableUI.paintCells(BasicTableUI.java:1974) javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:1770) javax.swing.plaf.ComponentUI.update(ComponentUI.java:143) javax.swing.JComponent.paintComponent(JComponent.java:763) org.openide.explorer.view.TreeTable.paintComponent(TreeTable.java:687) javax.swing.JComponent.paint(JComponent.java:1027) org.openide.explorer.view.TreeTable.paint(TreeTable.java:334) javax.swing.JComponent.paintToOffscreen(JComponent.java:5122) javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285) javax.swing.RepaintManager.paint(RepaintManager.java:1128) javax.swing.JComponent._paintImmediately(JComponent.java:5070) javax.swing.JComponent.paintImmediately(JComponent.java:4880) org.openide.explorer.view.TreeTable.paintImmediately(TreeTable.java:744) javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:723) javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679) javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659) javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128) java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) java.awt.EventQueue.dispatchEvent(EventQueue.java:597) org.netbeans.core.TimeableEventQueue.dispatchEvent(TimeableEventQueue.java:104) java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173) java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168) java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160) java.awt.EventDispatchThread.run(EventDispatchThread.java:121) RendererFactory.StringRenderer seems to be the responsible component.
StringRenderer correctly uses the color defined in look and feel "textInactiveText" for read-only values, which is javax.swing.plaf.ColorUIResource[r=172,g=168,b=153] in Windows look and feel. please note that this is default value defined by swing. so debugger can override this using html. html formating is used anyway for these values, so it's just a matter of adding some darker foreground color.
I really see no point in trying to hack that in debugger windows. This is a general problem in all read-only properties. Thus IMHO it should be fixed at one place in the property sheet and not in all modules that uses the property sheet. Roman suggested that i might be wrong to use disabled property for components that are not indended to be disabled, but just not to be modified. In any case, on Fedora the read-only properties are readable just fine, so perhaps the L&F should be adjusted or overriden...
FYI: We've verified that read-only properties in form have the same no-much-readable color as in debugger views.
> FYI: We've verified that read-only properties in form have the same no-much-readable color as in debugger views. that was exactly my point. you've been great help, thanks:)
the color for read-only cells in ttv/property sheet is consistent with the color of e.g. disabled buttons as is defined in swing's look and feel. so i'm closing this as 'wontfix' if you insist on this being a bug, please reopen and i'll file a bug against jdk. but you might be better off adjusting the color schema of your operating system where swings gets the disabled/readonly color from anyway.
I'm puzzled by the response. The color of disabled buttons seems completely irrelevant to how the debugger displays values for variables. Perhaps the "ttv/property sheet" is a poor choice for displaying debugger values? I'd like to agree with barty's comment early in this bug: "In any event, there are plenty of things in the IDE and on the desktop in general that are not editable. It would be silly if they were all greyed out, wouldn't it?" The values we're talking about are useful and important data. Making them very hard to read, just to indicate that they can't be edited, seems wrong.
Stando, could you file a bug against the JDK and tweak the L&F for NetBeans until it gets fixed in the JDK. I personally do not have any problem with the color, but on the attached image it's really hardly readable. There were more such complains. So I think it's worth it. AFAik we are tweaking default L&F on more places anyway, so it would not be the first case. Waiting for JDK L&F to be improved might take months.
Actually under GTK L&F, running JDK 1.6. it's really a problem. Attaching little clearer picture showing the problem.
Created attachment 56900 [details] Showing hardly readable form and debugger properties
> Stando, could you file a bug against the JDK and tweak the L&F for NetBeans until it gets fixed in the JDK not so easy, textInactiveText is a SystemColor, which changes with os color theme changes and i didn't manage to override it yet. i'll let our UI guru decide what we should do about this:)
IIRC there is some method in core or openide, which computes 'delta' between two colors and returns whether the contrast is good enough for human eyes. Might be it could be used in this case?
As a daily NetBeans user I would like to add support for this issue being resloved. It is hard to read and if you can't change the behaviour of the widget, perhaps change the widget. I'm not familar with the swing widget set, but using textInactiveText for a readonly property seems odd. The value is not inactive it's readonly. The widget is behaving like it is disabled. But it shouldn't be a disabled widget just a readonly one. It would seem that propertsheet has a flawed design if it treats readonly the same as disabled.
Why is the background color gray? Would it help if we make it white? On Win XP, a disabled button has gray background, but a disabled TTV field has white background. Disabled buttons are really different in usage, as there's generally just a few of them in a dialog box and they have simple names. The TTV values provide important information, so they should be rendered differently. Ideally the L&F would define better colors for disabled _table fields_, which doesn't seem to be the case. If changing the background color to white doesn't help, then we should probably override the L&F colors for all TTV and property sheet disabled fields (on Ubuntu only?).
> If changing the background color to white doesn't help, then we should probably override the L&F colors for all TTV and property sheet disabled fields (on Ubuntu only?). from the comments above i understood it is a problem on all platforms. so what background/foreground should i use for readonly values? ideally, the new colors should be derived from some system colors otherwise we'll get complaints when users switch to a non-default color schema (e.g. high contrast schema)
They mention Fedora is fine (not sure if it's Gnome, or KDE). The original bug description says Windows was okay as well. So can we do the same thing as on Windows where the property sheet doesn't follow the L&F values exactly as it doesn't modify the background color for disabled text values? Let's try to use just the foreground text color for disabled text value defined in L&F on Ubuntu as well. If it doesn't work well, then the only solution I can think of is to _not_ provide any kind of indication about "read-only" values in debugger tables. Use just regular font color and background. The property sheet is okay in this regard as easy to read values are not that important there, IMO.
fixed - tried to turn the gray background off for readonly values. the fix is a bit hacky as the current implementation of GTK laf ignores most color customizations (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527149) the fix applies for property sheet values as well. http://hg.netbeans.org/main/rev/f182c92af863
Created attachment 57490 [details] readable.png
It's way better now. We've just lost anti-aliasing of the affected cells, but that's minor problem in comparison with the original one. Thanks for the fix. Should I file separate issue for the anti-alisaing? It would make it even more readable. On the other hand if it is some neat problem to be fixed in the GTK or somewhere else, might does not worth it to workaround in NB?