@kovadam69
Just a small update - I've passed this issue to my colleague who made the recent changes, he will look into it once he has a bit more free time. There are certainly some issues with internal size calculations. It's been a wack-a-mole game for a while with the styled label layouting code as there are just too many cases (especially edge cases) which it needs to account for and the code itself is a bloody mess. Fixing one issue in that part almost always caused a few new ones, just like this time, so we'll need to be very careful.
So as I mentioned earlier - I recommend using more stable public v1.2.13 release for now, at least until v1.2.14 is patched up and finally released.
https://imgur.com/ZnjMNk6
It was the same a long time ago, then later some version fixed it, but now I have it again in 1.2.13 and 1.2.14 also (I don't remember now in 1.3.0-snapshot). But certainly it was fixed before. I don't know if it is a problem on windows, but certainly problem with Ubuntu 20.04.
I doubt that this issue was fixed in any of the versions, even 1.3.0 - most probably it's reproduction simply depends on the order in which you open popup menus. Unless there were some other changes that affected this somehow. The problem with the shadow stretching like this is simply an incorrect caching/retrieval of the generated shadow image and I don't think I touched that code yet due to some related difficulties.
Unfortunately not yet, different WebLaF modules indeed have similar packages which can cause issues on later Java versions but it's a huge change I can't afford right now. I will be changing packages once I'll move on from supporting Java 6+ along with lots of code adjustments for all new language features introduced in later Java versions.
@bgmoon
Theoretically you can use WebLaF inside existing UI designers like JFormDesigner, but practically there is an issue - WebLaF has to be initialized to work properly and unfortunately, as far as I know, none of the existing designers support that. And overall - I was developing WebLaF with mostly coding convenience in mind as I haven't really ever used UI designers as a tool to create UI code for any real-life projects. I do want to make WebLaF usable within UI designers without initialization but that will require some work and it is a bit further on the todo list.
WebLaF is not affiliated with JetBrains anyhow and isn't a plugin for any of their IDEs - it's just a standalone L&F library for Swing framework on Java, so I'm not sure how it can be available on JetBrains store (or marketplace? whichever you meant).
These are official artifacts published by me: https://search.maven.org/search?q=g:com.weblookandfeel
Other ones that may be available on Maven might simply be published by other WebLaF users and may be compiled from modified sources.That video is from a very old demo that was available before the major styling revamp in WebLaF (pre-1.2.9 versions). Not sure what you meant under image cropping, but the image gallery component is still available and it's component class is called
WebImageGallery. It haven't been added into new demo though because new demo only contains fully revamped and "cleaned up" components. It is still functional, but it will receive a rework in the future to be more customizable via new styling system.
And about the warnings - I recommend reading this wiki article: https://github.com/mgarin/weblaf/wiki/Java-9-and-higher
It should explain why those happen and how to configure your projects to avoid them.
@mikehearn
In runtime - currently no, but as a temporary solution I've added public static fields in WebLookAndFeel class that you can change to adjust global or specific component fonts, here are some examples:
WebLookAndFeel.globalControlFont // global font for ControlType.CONTROL
WebLookAndFeel.buttonFont // specific font for button components
WebLookAndFeel.checkBoxFont // specific font for check box componentsThere are a few issues with adjusting fonts in runtime, so that would still require some work to be done, but ultimately that's the goal of #331 and #352 issues
@mikehearn
I've looked at the issue with hotkeys on Mac and I found that there is indeed a separate class in AquaLookAndFeel that overrides default mapping:
https://github.com/openjdk/jdk/blob/702ca6228c7bcfaff6fa72e2f580daa7bb12f69a/src/java.desktop/macosx/classes/com/apple/laf/AquaKeyBindings.java
To fix this issue and avoid further inconsistencies with hotkeys I will need to create proper OS-specific mappings for all hotkeys registered within L&F. It's not a complicated solution but it will take more time than I expected, so the fix most probably won't be available until next week.
It also seems that #117 is an unrelated issue and will need further investigation and a potential fix (or a workaround, depending on what the problem is exactly).
@mattpymm You can include current snapshot version (v1.2.14) in your Maven project like this:
<dependencies>
<dependency>
<groupId>com.weblookandfeel</groupId>
<artifactId>weblaf-ui</artifactId>
<version>1.2.14-SNAPSHOT</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>sonatype-snapshot-rep</id>
<name>Sonatype snapshot repository</name>
<url>https://oss.sonatype.org/content/repositories/snapshots</url>
</repository>
</repositories>Or just download artifacts directly -
https://oss.sonatype.org/content/repositories/snapshots/com/weblookandfeel/
I currently have some urgent projects I got stuck on and which I need to finish before I can get to anything else and those are taking way longer than I expected.
So unfortunately all I can say right now is that I'll finish the fixes needed to release it as soon as it's possible.
Hi Mikle. I'm despaired trying to find the origin of this problem:
com.alee.api.clone.CloneException: Unable to clone object field: private final java.beans.PropertyChangeSupport com.kitfox.svg.app.beans.SVGIcon.changes
at com.alee.api.clone.behavior.ReflectionCloneBehavior.clone(ReflectionCloneBehavior.java:133)
at com.alee.api.clone.Clone$InternalClone.clone(Clone.java:137)
at com.alee.api.clone.Clone.clone(Clone.java:109)
at com.alee.extended.svg.SvgIcon.clone(SvgIcon.java:483)
...
Caused by: java.lang.NoSuchMethodException: Constructor was not found: java.beans.PropertyChangeSupport()
at com.alee.utils.ReflectUtils.getConstructor(ReflectUtils.java:1374)
at com.alee.utils.ReflectUtils.createInstance(ReflectUtils.java:1274)
at com.alee.utils.reflection.Unsafe.allocateInstanceThroughReflection(Unsafe.java:127)
at com.alee.utils.reflection.Unsafe.allocateInstance(Unsafe.java:62)longer trace here: https://gist.github.com/Sciss/00b3de940e4591e452ff1f44f787472c
It's a complete head-scratcher, because I never had problems with JFileChooser before. This is based on an older version I think 1.2.11 of WebLaF. I use exactly the same version in another application without problems. It only happens when I bundle the JDK (AdoptJDK 11). It must be some weird Heisenbug, something to do with initialization I think, because it doesn't show up under very similar circumstances. Any idea what might cause this, and if there is a work-around (perhaps some explicit init order)?
JFileChooser
Hm, this does seem like something that could happen, although I've never seen that exception at that specific place before either.SVGIcon does contain PropertyChangeSupport instance that strictly may not be cloneable if Unsafe is not useable on your Java version.
You can actually see from this part of the trace:
com.alee.utils.reflection.Unsafe.allocateInstanceThroughReflection(Unsafe.java:127)
com.alee.utils.reflection.Unsafe.allocateInstance(Unsafe.java:62)That WebLaF's Unsafe tried to allocate object instance via sun.misc.Unsafe and failed.
As a result it attempted to create instance via empty constructor and also failed resulting in the error.
There is a third option of instance allocation, but it only applies to Serializable objects and PropertyChangeSupport is serializable, so it's weird why it didn't go further. Or it did and failed at that attempt as well, it's hard to say since the stack trace code lines seem to mismatch the class sources.
WebLaF's Unsafe for reference -
https://github.com/mgarin/weblaf/blob/c5d6b3931879a4da2fdebf7ee01868f1969d75f4/modules/core/src/com/alee/utils/reflection/Unsafe.java#L56
It is somewhat unusual for all three ways of instance allocation to fail though.
@geniot
Currently majority of L&F boot time is reading & compiling of XML styles into runtime objects that are then used by component UIs.
The only way to reduce boot time with current implementation, unfortunately, is to reduce amount of styles that are loaded.
It is possible to do via creating a fully custom skin with only the styles you need, but that is a tedious and quite lengthy task.
That being said, since the last year I've been working on an improving the approach to load & compile styles to reduce boot time dramatically.
To put it simple - styles will be compiled lazily on demand instead of having all of them compiled at initialization.
I still haven't finished all of the changes unfortunately, but they will be included in v1.3.0 once it goes live.
You can read more about it here: #595
I had that update planned to go live last year, but unfortunately I didn't have enough time to finish working on it up until now.
I absolutely do plan to get back to it as soon as possible, but I can't really give any specific ETA on it.
I am also planning to finish some smaller bugfixes and improvements in v1.2.14 and release it soon, but boot time improvements will take more time to complete as that part is crucial and have to work perfectly under all circumstances (with all style variations and existing styling system features).
I tried that approach at some point, but compiled styles are much heavier and you'll be trading overhead of reading a few of them from the drive and compiling them for overhead of reading a lot of them from the drive. Whether compiled styles are in XML or in some binary format didn't seem to matter much, read time would take all the time that is taken by the compiling right now. It might seem like a good idea at first, but in reality - it will result in approximately the same boot time, it will of course vary depending on how fast your drive is and how fast your CPU is. Current approach is mostly CPU-heavy (works much faster on higher-clocked CPUs), precompiled approach would be both drive-heavy and CPU-heavy due to the sheer amount of styles to be loaded (1000~1500).
As for Reflection - it is used a lot to create UIs and Painters and to update their settings which happens whenever components are created and not at the L&F boot, so Reflection isn't just used during the boot time but also in runtime. But that doesn't matter too much anyway because Reflection is pretty fast in newer JVM versions plus I have a lot of cache in place that makes methods & fields lookup quick and easy, so it doesn't actually affect performance as much as you might think it does.
In general I agree that Reflection should be used as little as possible or not used at all, but the reality is - it would take exponentially more time to write and support an agile styling system for all existing component variations without using it. Another issue is - some Reflection calls are also necessary to access proprietary Swing APIs to enable/fix various things - for instance to properly utilize system fonts or to acess some Window features that weren't public in earlier Java versions. Some of those issues will go away once WebLaF stops supporting Java 6 and switches to higher lowest supported version, but for now it's just not possible to get around without Reflection usage.