Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 06 17:53
    mgarin closed #655
  • Jun 06 17:53
    mgarin commented #655
  • Jun 06 17:49
    mgarin closed #659
  • Jun 06 17:49
    mgarin commented #659
  • Jun 06 17:48
    mgarin commented #662
  • Jun 06 17:47
    mgarin closed #662
  • Jun 06 17:46
    mgarin commented #662
  • Jun 06 17:45

    mgarin on master

    Table [ #662 ] - TableRowHeight… (compare)

  • May 29 10:02
    mgarin commented #664
  • May 29 10:01
    mgarin commented #665
  • May 28 18:51
    mokun commented #664
  • May 28 18:49
    mokun commented #665
  • May 18 20:19

    dependabot[bot] on maven

    (compare)

  • May 18 20:19
    dependabot[bot] closed #663
  • May 18 20:18
    dependabot[bot] commented #663
  • May 18 20:18
    dependabot[bot] labeled #666
  • May 18 20:18
    dependabot[bot] opened #666
  • May 18 20:18

    dependabot[bot] on maven

    Bump xstream from 1.4.12 to 1.4… (compare)

  • May 12 10:46
    mgarin commented #664
  • May 12 10:42
    mgarin commented #665
kovadam69
@kovadam69
The text should have been wrapped like this:
Asdfasdf 12345678-12345678-12345667
AA123456781234556767
Instead of:
Asdfasdf
12345678-12345678-12345667 AA123...
Also tried to remove the setBoldFont() call, but it made no difference
kovadam69
@kovadam69
I did debug a little bit, and I found out, that for some reason at painting the bounds of the painting area is reduced. With my test the getPreferredTextSize gave bounds of 427x77pix, and it passed also this bounds to the painting, but at some point something reduced the bounds size to 268x28px, which caused the text to be wrapped at a different point... It happened in the AbstractContentLayout.layoutContent method. 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 IconTextLayout for some reason it reduces the size...
Mikle
@mgarin

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?

And I suppose that screenshot was from example running using WebLaF v1.2.14-SNAPSHOT version?
Mikle
@mgarin
Either way, I can certainly reproduce it on the latest version, so something is certainly wrong. I'll see if it's possible to fix it quickly, for now I would recommend using last released v1.2.13 version - it doesn't have these changes, so it should be at the very least behave the same way older versions did.
kovadam69
@kovadam69
Thanks, Java version was 1.8.0_171 I think, and it was 1.2.14 latest snapshot.
Mikle
@mgarin

@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.

kovadam69
@kovadam69
Thanks! I will wait for the 1.2.14 update. I've found another issue with popup menu (or similar popup windows):
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.
kovadam69
@kovadam69
I tried now 1.3.0-SNAPSHOT and it seems there is no problem (glitch) with popup menu, so it is 1.2.x related.
Mikle
@mgarin
@kovadam69
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.
kovadam69
@kovadam69
ah, OK, just with 1.3.0-SNAPSHOT it was gone, and I was using 1.3.0-SN since April or so, and now I switched back to 1.2.14-SN and then to 1.2.13 and I immediately noticed the problem again.
Mikle
@mgarin
@kovadam69
Styled label wrapping issues were potentially fixed with the latest commit.
I'll still need some time before I release v1.2.14, but you can give it a try to see if it works correctly for you - snapshot version is already available.
kovadam69
@kovadam69
@mgarin Hi! I tried, and the wrapping issue seems to be gone now :) Great job! Thanks!
Javier Coindreau
@javster101
Hello! I was wondering if weblaf officially supports using java 9+ modules? I am having an issue with repeated packages between weblaf.ui and weblaf.core that are preventing a build with Gradle and Java 14
Javier Coindreau
@javster101
Actually nevermind, I got it figured out
Mikle
@mgarin
@javster101
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.
Lord Moon
@bgmoon
I'm currently developing a fairly extensive desktop application and have been using JFormDesigner (in intelliJ) with flatFlaf. I'm considering switching to your framework because of several of your better components but have some questions: 1) Is there a similar GUI based UI designer like JFormDesigner that I can use? 2) Why can't I just buy your LAF through the jetbrains store? 3) I found two projects that seem to both be "webLaf" on maven central, which is yours? 4) I found a video on youtube (https://www.youtube.com/watch?v=CiTXm7wlgZE) that seems to be webLaf, but the demo is quite different than the one I downloaded form gitHub in functionality. In particular, there are things in that video I would like to have, especially the image gallery and image cropping, but don't find them in the git hub repo. Are these the same product? Do you support those image capabilities?
BTW, I'm able to build and run a simple demo under Java 14/15 with no issues other than warnings.
Mikle
@mgarin

@bgmoon

  1. 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.

  2. 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).

  3. 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.

  4. 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.

Mike Hearn
@mikehearn
I'm curious if there's a way to change the default font size, for zooming? I often like to zoom text in web browsers and this is a common lack in desktop apps.
Mikle
@mgarin

@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 components

There 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

Mike Hearn
@mikehearn
Thanks. Also, I noticed in the text inputs that a lot of hotkeys don't seem to work (on Mac). For instance cmd-left, cmd-right, cmd-a to select all etc. Is that also a known issue?
Ctrl-A does work. Seems like the keymap doesn't realise i'm on a Mac. This is with Java 15.
Mikle
@mgarin
I think there is an issue with the cmd key specifically, yes.
I really need to get some test mac os running and fix it, these might be related as well: #117 #176
I bumped these issues to the next update v1.2.14 update and will look into them.
Most probably - it's just a global key mapping issue as I'm mostly testing under Windows & Unix where cmd key isn't really a thing.
I'll see if I can make a quick fix tomorrow as it is actually a deal-breaker bug for Mac users.
Mike Hearn
@mikehearn
Cool
Mikle
@mgarin

@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
@mattpymm
@mgarin You mentioned a snapshot build on #651 where could I find that?
Mikle
@mgarin

@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/

mattpymm
@mattpymm
Thanks! @mgarin
mattpymm
@mattpymm
@mgarin Is there an estimated release date for v1.2.14?
Mikle
@mgarin
Can't really say anything specific as I'm not sure when I'll have enough time to work on it right now.
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.
Hanns Holger Rutz
@Sciss

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)?

it's when trying to use JFileChooser
Hanns Holger Rutz
@Sciss
FileChooserUI happens to be the only UI class I am overriding in my look-and-feel:
    @Override
    protected void initClassDefaults(final UIDefaults table) {
        super.initClassDefaults(table);
        table.put("FileChooserUI", SubminLookAndFeel.fileChooserUI);
    }
Heisenbugs usually to do different hash codes and problems with traversal of "unordered" collections like sets and maps; my intuition
Unfortunately updating WebLaF to latest version is difficult, because I will have to adapt my skins whose API changed a lot I think
xstream seems an eternal source of problems
Hanns Holger Rutz
@Sciss
it's cursed because it only happens with bundled JDK and I cannot use the step debugger in IntelliJ to see what's going on
Hanns Holger Rutz
@Sciss
Ok. I found the difference in the two projects. The one that works had jlinkModules += "jdk.unsupported". D'oh. I don't know how this working before in the other project. Clueless. Anyway, that solves it
Mikle
@mgarin

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.

Hanns Holger Rutz
@Sciss
I think it's that Unsafe was moved to jdk.unsupported somewhere "during" JDK 11, like older versions had it included in the default, newer ones not. At least that's my explanation. So worth noting that one needs to include that module if using a self-contained JDK bundle.
Mikle
@mgarin
That makes sense
ys1113457623
@ys1113457623
Can someone help me how to install weblaf
?
its showing this ERROR com.alee.laf.NativeFonts - Unable to check Font default encoding support
Can someone help me
Mikle
@mgarin
@ys1113457623
Can you provide a full stack trace?
Also what Java version are you using? and which WebLaF version you're trying to install?