When we instantiate a Darklaf we have to create the base laf.
For macOS this may require us to install the system laf in the
UIManager. We should restore it the way we found it to ensure
no surprises if one instantiates Darklaf without trying to install
it directly afterwards. Because this makes the instantiation heavier
we skip the restoring if we know we are installing the laf directly
afterwards e.g. when installing through the LafManager.
Both are scheduled for removal and only occur because
the respective code replicates JDK classes. All occurrences
aren't strictly necessary hence can be removed.
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
This allows us to move the dependency versions back into
gradle.properties so version for plugins and dependencies are declared
in a centralized way.
This commit also removes the legacy macOS framework dependencies.
The new version provides an easier and more versatile API. The old one still remains
available as some uis rely on some more involved quirks of the old implementation.
However, the new and old version share the same animation thread.
The fix for non-transparent tooltips on X11 surfaces involved disabling double buffering
for the component hierarchy. Somehow this doesn't seem to work on Java 8. Luckily it is
a version where we are free to apply the reflection hack to fix it.
This fixes#274
This only changes os specific properties supplied by the Theme.
It won't load the os dependent base laf or decorations provider
as they generally won't be available. Also some properties
may be different from the platform default as they are set the
first time the laf is installed.
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.