Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NETBEANS-3592] Workarounds for JDK Windows LAF bugs on HiDPI screens #1777

Merged
merged 3 commits into from
Jan 3, 2020

Conversation

eirikbakke
Copy link
Contributor

@eirikbakke eirikbakke commented Dec 13, 2019

Provide workarounds for various JDK bugs that caused the Windows LAF to be unusable on many HiDPI configurations, typically when an external monitor (or projector) is involved, or is disconnected or connected. Summary:

  1. Fix tiny or huge GUI font size on various configurations.
  2. Fix tiny or huge UI control icons when main monitor was not the HiDPI monitor at logon. (Workaround for https://bugs.openjdk.java.net/browse/JDK-8211715.)
  3. Fix uneven borders on text components on non-integral HiDPI scaling factors (e.g. 150%). (A similar improvement was previously done for the NetBeans tabcontrol borders, see [NETBEANS-2646] Improve tabcontrol border appearance (HiDPI) #1284 .)

See full details on https://issues.apache.org/jira/browse/NETBEANS-3592

Problem 1, incorrect font size
Problem 2, OS controls wrong size (before patch)
Problem 2, OS controls wrong size (after patch)
Problem 3, uneven text component borders
WindowsSwingMultiMonitorTest

1) Fix tiny or huge GUI font size.
2) Fix tiny or huge UI control icons. (Workaround for JDK-8211715.)
3) Fix uneven borders on text components on non-integral HiDPI scaling factors
   (e.g. 150%).

See JIRA issue for more details, screenshots, and a manual test plan.
@eirikbakke eirikbakke changed the title [NETBEANS-3592] Fix various Windows LAF bugs on HiDPI screens [NETBEANS-3592] Workarounds for JDK Windows LAF bugs on HiDPI screens Dec 13, 2019
@lkishalmi
Copy link
Contributor

lkishalmi commented Dec 13, 2019

Well for me it looks insane. In a good way of course. Thank you!

@@ -154,6 +154,7 @@ public static void initCustomFontSize (int uiFontSize) {
switchFont("windowTitleFont", fontTranslation, uiFontSize, nbDialogBold); // NOI18N
switchFont("Spinner.font", fontTranslation, uiFontSize, nbDialogPlain); // NOI18N
switchFont("FormattedTextField.font", fontTranslation, uiFontSize, nbDialogPlain); // NOI18N
switchFont("Slider.font", fontTranslation, uiFontSize, nbDialogPlain); // NOI18N
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Should add // NOI18Ns to strings of the other files that are not expected translation as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do.

private DPISafeBorder(Insets insets, Color color) {
if (insets == null)
public static Border fromDelegate(Border delegate) {
if (delegate == null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use curly braces({}) although existing code doesn't use them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, my humble opinion is that we shall avoid throwing NullPointerExceptions directly from the code. It would be better to do an assert <whatever> != null; instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add curly braces... I keep forgetting the code style. (The previous code was mine, too.)

Assertions can be disabled, which make them more or less useless for enforcing invariants--no way to know down the line whether they were enabled or not (e.g. when reading a log file while trying to debug an intermittent problem down the road).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree - I tried to run netbeans with substance laf (or one of its siblings) and the author decided to enforce the "things interacting with GUI have to run on the EDT" rule. I ended badly (netbeans tries to do to much work off the EDT) and if Swing would have enforced the rule, netbeans could not have gone down the path in the first place. Now it is difficult to get rid of this.

The Code can be made better readable by using java.util.Objects#requireNonNull, then the missing braces will also not be a problem :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, we can also use @NonNull to make "non-null" clear ? e.g. public static Border fromDelegate(@NonNull Border delegate)

Copy link
Contributor

@matthiasblaesing matthiasblaesing Dec 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the annotations we'd need a dependency on Common Annotations. That module causes headaches: #1764. DPISafeBorder#fromDelegate is a method, that is only called from within the module, so I would not put to much API thoughts into it.

… pixels thick. Improve JSpinner borders. Fix style.
@eirikbakke eirikbakke merged commit 79ad0e9 into apache:master Jan 3, 2020
svenreimers pushed a commit to svenreimers/netbeans that referenced this pull request Jan 6, 2020
…apache#1777)

Details:
1) Fix tiny or huge GUI font size.
2) Fix tiny or huge UI control icons. (Workaround for JDK-8211715.)
3) Fix uneven borders on text components on non-integral HiDPI scaling factors (e.g. 150%).

See JIRA issue for more details, screenshots, and a manual test plan.
@eirikbakke
Copy link
Contributor Author

I've left a link to this patch at the original JDK bug for the icon scaling issue, at https://bugs.openjdk.java.net/browse/JDK-8211715 .

@sopgreg
Copy link

sopgreg commented Mar 11, 2020

@eirikbakke We just saw your pull request. Do you plan on opening OpenJDK tickets for the border thickness and icon scaling bugs and provide this patch to the OpenJDK? We would like to use these bugfixes in a standard L&F for our applications.

@eirikbakke
Copy link
Contributor Author

I already opened a ticket for issue 2 (icon scaling; JDK-8211715) and was working on a report for issue 3 (border widths). If you want, feel free to submit a ticket for issue 1 (font scaling).

I don't have a dev environment set up to build the JDK itself, so I'm unlikely to submit JDK patches myself. Note that the workarounds here are not patches that can be applied against the JDK itself--though you can certainly copy them into your client applications.

@beth-soptim
Copy link

There's now an issue in the OpenJDK bug tracker concerning the "line thickness": https://bugs.openjdk.java.net/browse/JDK-8241561

@eirikbakke
Copy link
Contributor Author

@problemzebra2 Ah, great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants