To do this the following restructuring is performed:
- Move decorations specific classes to darklaf-platform-decorations
- Move SystemInfo to darklaf-platform-base
- Move theme specification specific classes to darklaf-theme-spec
- Create new module darklaf-platform-preferences for the reporting related classes
Some modules explicitly export only to darklaf.core, because
they are implementation modules. To avoid compiler warnings
we stub the module definition.
Currently, the JDK doesn't correctly report the current operating system.
For now, we query the value ourselves using native code. This will be updated
once the JDK backport is available:
https://bugs.openjdk.java.net/browse/JDK-8274840
When running on Windows 11 don't need to extend the client frame
anymore. This allows us to give back the titlebar space to the window manager.
Hovering over the maximize button now yields in the snapping popup to appear.
We should give the os enough space outside the frame to handle the
resize area itself.
This avoids issues with scrollbars at the window edge etc.
Fixes#266
It was only used on Windows, where it is currently always
an effective no-op as the insets were adjusted by zero
values. In fact with non-zero adjustments the result was
an incorrectly sized window.
We add a custom task to compile the module-info with a newer java version.
To ensure the module-info is correct we need to compile it together with all other project sources.
Upload the arm64 library on macos so it can be consumed by the build on other platforms. We also print the file information to check that the produced library really targets the correct arch.
To do this properly we add new flags to SystemInfo indicating whether the current arch supports X86 or is an ARM/M1 based cpu. The X86 support detection is most definitely incorrect but will work for most common processors. Relates to #240