[regression] In Java apps like Netbeans, dark menu bars don't look good for disabled elements
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Ubuntu theme |
Low
|
Unassigned | ||
| openjdk-8 (Ubuntu) |
Low
|
Unassigned | ||
| openjdk-9 (Ubuntu) |
Low
|
Unassigned | ||
| ubuntu-themes (Ubuntu) |
Low
|
Unassigned |
Bug Description
This fix, #961679, specifically Ambiance/
Unfortunately I'm not aware of an easy way to get screenshots of open menus, so hopefully these attached phone pictures of Netbeans are enough to illustrate the issue.
As you can see it is hard to tell the difference between what is disabled and what isn't, and the disabled items look fuzzy (easier to observe on monitor).
I really don't see the issue with lighter menus, but if they must stay dark then the readability / contrast of disabled items needs to be fixed.
Thanks
md_5 (md-5) wrote : | #1 |
md_5 (md-5) wrote : | #2 |
md_5 (md-5) wrote : | #3 |
Daniel van Vugt (vanvugt) wrote : Re: In Java apps like Netbeans, dark menu bars don't look good for disabled elements | #4 |
Confirmed. But the problem is just Java failing to pay attention to the theme correctly. It uses the right background colour, but not the right font colours. It's still using a fixed font colour that works only on lighter backgrounds. This is a bug in openjdk-8 (or netbeans itself, not sure).
summary: |
- Fix for #961679 - dark menu bars doesn't look good for disabled elements + In Java apps like Netbeans, dark menu bars don't look good for disabled + elements |
affects: | ubuntu-themes (Ubuntu) → openjdk-8 (Ubuntu) |
Daniel van Vugt (vanvugt) wrote : | #5 |
Although if you say everything was fine before the fix for bug 961679 then this is a regression and it possibly is the fault of ubuntu-themes :)
summary: |
- In Java apps like Netbeans, dark menu bars don't look good for disabled - elements + [regression] In Java apps like Netbeans, dark menu bars don't look good + for disabled elements |
Launchpad Janitor (janitor) wrote : | #6 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in openjdk-8 (Ubuntu): | |
status: | New → Confirmed |
Changed in ubuntu-themes (Ubuntu): | |
status: | New → Confirmed |
Changed in ubuntu-themes: | |
importance: | Undecided → Low |
Changed in openjdk-8 (Ubuntu): | |
importance: | Undecided → Low |
Changed in ubuntu-themes (Ubuntu): | |
importance: | Undecided → Low |
Changed in ubuntu-themes: | |
status: | New → Confirmed |
tags: | added: visual-quality |
md_5 (md-5) wrote : | #8 |
Java isn’t hardcoding them, it’s pulling them from GTK. There is the possibility that it’s pulling the wrong type of element colour (sorry not sure about terminology).
I guess the test is to find a GTK 2 app with disabled menu elements that previously had a white menu which is now black wih this patch.
I did make a test Java Swing app and the disabled elements looked bad, so it’s not constrained to Netbeans at least.
Daniel van Vugt (vanvugt) wrote : | #9 |
I think it's more the Swing/other toolkit's unique way of rendering things than GTK. Testing a native GTK-2 app (geeqie) doesn't seem to exhibit the problem.
Yes I agree with your terminology. Worth noting though even the font rendering style looks messed up in Netbeans. From what I recall in years gone by that's a Java-specific issue.
md_5 (md-5) wrote : | #10 |
If you were testing your own install the font rendering is messed because of this bug in freetype https:/
Downgrading to the Zesty version of freetype (as in my screenshots) fixes that issue.
md_5 (md-5) wrote : | #11 |
Java looks to be using the disabled foreground colour correctly (to me, the untrained observer):
gtk2_widget = gtk2_get_
GtkStyle* style = gtk2_widget->style;
switch (color_type)
{
case FOREGROUND:
color = &(style-
break;
Worth noting using GTK3 breaks other things, but actually fixes this bug (but that could simply point to an issue with Java's GTK2 code).
md_5 (md-5) wrote : | #12 |
Ok Turns out Java has some super funky code:
int componentState = context.
if ((componentState & SynthConstants.
if (!GTKLookAndFee
x += 1;
y += 1;
x -= 1;
y -= 1;
}
}
Removing this silly +1 white shadowing nonsense results in perfect looking menus both when dark and light.
I will take this upstream and see if it can be patched into Ubuntu, not a theming bug after all.
Changed in ubuntu-themes: | |
status: | Confirmed → Invalid |
Changed in ubuntu-themes (Ubuntu): | |
status: | Confirmed → Invalid |
md_5 (md-5) wrote : | #13 |
Patch I submitted upstream is attached, not through yet though.
Daniel van Vugt (vanvugt) wrote : | #14 |
Great, thanks. Do you have a link to the upstream bug?
Changed in openjdk-9 (Ubuntu): | |
importance: | Undecided → Low |
md_5 (md-5) wrote : | #15 |
No upstream bug yet unfortunately (OpenJDK bugtracker is restricted access as I'm sure you know).
I made a mailing list thread a few days ago here http://
The attachment "disabled.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
tags: | added: patch |
md_5 (md-5) wrote : | #17 |
Patch was applied upstream,
http://
Requesting a backport to 8/9 please. Should apply without conflicts - file hasn't been otherwise modified in either version.
Thanks
Michael
Launchpad Janitor (janitor) wrote : | #18 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in openjdk-9 (Ubuntu): | |
status: | New → Confirmed |
Firefox / Libreoffice etc which I'm guessing use gtk3 show disabled items fine.