AbstractContentLayout.layoutContentmethod. It gets the correct bounds of 427x77, but at the call to
final ContentLayoutData layoutData = layoutContent ( c, d, bounds );it gets back a smaller rectangle. It happens in
IconTextLayoutfor some reason it reduces the size...
Thanks for code example, I'll look into that.
It is really weird though, maybe the issue is tied to the particular wrapping method or something else very specific.
I have thoroughly tested
WebStyledLabel changes when they were pushed and it didn't seem to have such glaring problems.
One more thing - what Java version are you using for the test?
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.
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.
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 components
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:
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 -
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)?
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:
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.
It is somewhat unusual for all three ways of instance allocation to fail though.