What JDK are you using? (early JDKs do not support HIDPI screens properly)
If you’re on a recent JDK, adding -Dglass.gtk.uiScale=200% to your JVM options at startup might help (it helps with JavaFX apps on Mac but I don’t know about Swing).
If you are stuck on a java 1.8 or older jvm, default seesaw won’t be good at high res. However, the Substance theme (I first learned of from the original nightcode editor swing implementation) will scale. It has some really strict UI threading requirements that default swing doesn’t, so interactive gui editing from a repl thread works (technically unsafely) in seesaw / normal swing, but throws concurrent access errors in substance. I have a wrapper called saner substance that should correct this. You just set the platform look and feel like here and you should be good to go. On my hidpi 4k display it looks great.
Cool, that led to this: https://github.com/kirill-grouchnikov/radiance which seems like a quite nice set of additions for writing modern Swing apps. Looking at those, almost feels more appealing then JavaFx. Though its Java 9+ only.
Substance and related themes are really nice to see “in action”; since they have cool little animations and subtle effects that are just excellent. I’m sure there are javafx versions/variants, but swing with substance feels advanced (despite being swing, hah).
If you have seesaw and the saner-substance library in your dependencies, this should set your theme to substance, with the fixes I put in, and hidpi should work (it does for me on older jvms). I have not tested on mac though, but it works on linux and windows.
Looks like it’s a problem with jdk 14 (I run on 8, since I target some legacy systems).
On a demo project with clojure 1.10.1, and saner-substance as the only dependencies, everything works fine. The difference is in this line:
(SubstanceLookAndFeel/setSkin (GraphiteSkin.))
I get true (e.g. it was successful). I don’t know what changed with swing and substance in Java 14, hmm.
I got true after restart CIDER REPL, eval it again, then I got false.
Don’t know is this a problem. From your words, it should be right.
================
And the the second error.
When I eval frame code, I got Unhandled java.lang.NullPointerException in org.pushingpixels.substance.internal.utils.SubstanceColorUtilities/getDefaultBackgroundColor.
I tried to execute it manually, but don’t know what argument does it accept. So can test it.
I will try to switch to older JDK version. Hope got correct result. Thanks @joinr
– UPDATE–
I tried JDK 11 version. Same error: Unhandled java.lang.NullPointerException, org.pushingpixels.substance.internal.utils.SubstanceColorUtilities/getDefaultBackgroundColor as upper second pasted backtrace.
I don’t think JDK 11 is “old” enough. That is, it looks like things changed around Java 9 (when they started going toward faster releases, introduce the module system, etc.). It could have something to do with how swing is or isn’t being initialized in Java 9+, I am not sure. Perhaps there are classes that are being elided. You could always try JDK 8 just to see (like install adopt open jdk). It may be possible to coax out the correct behavior, although the new version of substance (under radiance now) is only meant to be JDK 9+. So probably the better bet would be to use the radiance library, set the substance theme that way (slightly different than the code I posted), and see how things work out. unfortunately, I do not have a wrapper like saner-substance for the radiance/substance stuff, so you will have to invoke everything on the swing dispatch thread I believe. I think it’s seesaw.core/invoke-later or seesaw.core/invoke-now for async or sync variants.
Here’s a demo repository that works with Java 14 on windows. It’s using the newer substance (which is java 9 or greater), and is not using the convenience wrappers from saner substance, so everything that seesaw does to create swing components “has” to be done on the event dispatch thread (e.g. via seesaw.core/invoke-now or invoke-later), or else substance will throw a bunch of concurrent access exceptions at you when rendering components. As an aside, on Java 14, Windows, my font is already HiDPI scaled perfectly (prior to using substance). There may be some platform-specific problems going on that I’m not familiar with.
Yes, I would not mess around with “saner substance”; if you are using Swing, you should get used to working with the way Swing works, and only try to manipulate UI elements on the Swing event dispatch thread, using invoke-now from the REPL (if you want to see the result) or invoke-later if you don’t care to.
I’ve been using Substance with the Raven skin to great effect in my Beat Link Trigger project, and sneakily getting more and more people involved in performing music and light/laser shows to learn a little Clojure. It works with JDK 9 or later on all OSes; I embed an OpenJDK 14 distribution in my macOS and Windows installers.
“saner substance” obeys swing’s idioms; it just forces component creation to default to ensuring EDT. The type of repl driven development that seesaw encourages will work fine, right up until you run into substance’s hardcore thread protection. None of this is an issue with stock swing stuff (at least, it’s not presented as an issue via exceptions). IME this is overkill. So you are now back to doing everything manually on the EDT, particularly if you’re doing a lot of interactive development and prototyping. Substance’s complaining about non-EDT invocation gets old fast, hence wrapper classes that have worked fine for ~4 years in production (in a legacy Java 8 environment though). Were I to migrate to Java 9+, I would wrap the classes again.
In theory, JDK 14 should render correctly with or without substance. I am afraid you are entering territory I am unfamiliar with regarding the native platform interactions with display scaling