Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 21 20:13
    tullisar commented #698
  • Jun 21 20:12
    tullisar commented #698
  • Jun 21 10:33
    mgarin commented #698
  • Jun 21 10:32
    mgarin commented #698
  • Jun 17 10:28
    mgarin commented #662
  • Jun 16 23:41
    tullisar commented #662
  • Jun 16 11:11
    mgarin commented #698
  • Jun 16 11:05
    mgarin commented #698
  • Jun 15 17:50
    tullisar commented #698
  • Jun 15 12:09
    mgarin commented #698
  • Jun 15 12:09
    mgarin commented #698
  • Jun 15 12:06
    mgarin commented #698
  • Jun 10 02:34
    tullisar commented #698
  • Jun 02 01:48
    wyj3531 closed #700
  • May 23 11:49
    mgarin commented #700
  • May 23 11:48
    mgarin commented #700
  • May 20 01:43
    wyj3531 labeled #700
  • May 20 01:43
    wyj3531 assigned #700
  • May 20 01:43
    wyj3531 opened #700
  • May 12 14:32
    mgarin commented #699
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?
geniot
@geniot
image.png
Hi, is there any way to minimize the bootstrap time?
Mikle
@mgarin

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

geniot
@geniot
Thanks for this elaborate answer. As I look at it: for faster loading all styles should be precompiled into classes and no reflection should occur at runtime.
Mikle
@mgarin

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.

Mikle
@mgarin
So to summ it up, the only solution that will bring reasonable boot time improvements right now - making it lazy. It doesn't exclude read time from the boot, but it will still reduce boot time by about 5~7 times in most cases. It will shift some of the compiling towards component initialization time, but from what I can tell so far - it will be inconsequential for most applications as from my experience you will normally be using around 100~150 different component styles, up to 300 in some rare cases, but definitely not all (1000~1500) available ones. The initialization time per single style will remain the same but you'll only be loading 10~20% of the existing styles and even that will be split across your application UI initialization (whenever a component is created - style for that component will be compiled if it wasn't before) making way less of an impact on the overall boot time in many cases.
geniot
@geniot
Ok, I see it now. If it's CPU then indeed lazy loading is the answer. Thanks a lot for this explanation. I'm going to continue my experiments with WebLaF. It looks extremely good.
Mikle
@mgarin
WebLaF is good in terms of styling capabilities but has it's own issues compared to other L&Fs - like the long boot time, Reflection usage, a bunch of extra 3rd-party libraries it carries along. Also you probably want to fine-tune the styles for your application if you use WebLaF because while using it out-of-the-box is definitely possible - it will end up looking worse than some of other existing L&Fs out there. Major advantage is that there are quite a few useful extras built-in with WebLaF (both components & features) and the ability to fine-tune everything. But there is still a lot of work to be done on my side though, as always with any development.
Abu-Abdullah
@Abu-Abdullah
Hi @mgarin , can i increase the size of all default LaF icons to (24 x 24) instead of (16 x 16). is there an easy way for this
Mikle
@mgarin

@Abu-Abdullah
Most icons in components that I have moved to new styling system are defined in icon sets, so it should be possible to simply replace them.

You can find two existing icon sets here:
https://github.com/mgarin/weblaf/tree/master/modules/ui/src/com/alee/iconset

Their definition, similarly to skins, can be found in according XML files, for example light one:
https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/iconset/resources/light-icon-set.xml

To replace any icon from existing icon set you simply need to register new icon set with the icon that has the same identifier as the one you want to replace.
Both old and new sets will be preserved, but sets that are registered last will have priority when icons are retrieved.
This is sort of a temporary solution while there is no better way to replace/override icons from existing sets, but it should suffice.

In your case you might need to replace all icons from the core icon set and simply provide new size, for example:

<!-- General purpose icons -->
<SvgIcon id="underline" path="underline.svg" size="24,24">
    <SvgFill selector="svg" color="80,80,80" />
</SvgIcon>

It should work fine since all icons are SVG-based and can be rescaled without any issues in runtime.

Once you have created your custom icon set XML definition with all icons reconfigured to 24x24 size you will need to provide that icon set into IconManager.
To do that you will first need to create a small class extending XmlIconSet, like the core LightIconSet, for example:

public final class MyIconSet extends XmlIconSet
{
    public MyIconSet ()
    {
        super ( new ClassResource ( MyIconSet.class, "resources/my-icon-set.xml" ) );
    }
}

Then you simply need to add it into IconManager from the code:

IconManager.addIconSet ( myIconSet );

Or by specifying it in your custom skin or skin extension (if you have one):

<iconSet>com.test.MyIconSet</iconSet>

Both options are valid, but second one might be more convenient if you already have a custom skin or skin extension.

You can also check wiki article about IconManager usage:
https://github.com/mgarin/weblaf/wiki/How-to-use-IconManager

The main issue with that approach - and why I called it a "temporary solution" - is keeping your custom icon set up-to-date.
There won't be any issues if you miss some icons, but those will be rendered with their default settings from core set.

Ultimately there might be some better ways to implement icons scaling/recoloring without having to overwrite the whole set.
Maybe similar to variables solution that will be introduced for skins and styles, but I haven't really looked into that yet.

Abu-Abdullah
@Abu-Abdullah
many thanks @mgarin , it works with me after few attempts. appreciated
kovadam69
@kovadam69
@mgarin Hi! We talked a long time ago about FileChooser beeing super slow especially for network drives. You said you should migrate to NIO, but for that you have to go for JDK 7 at least. Is there a chance to have it in the near future? Problem is, that because of the slow filechooser performance, I use javax native file chooser, which is super fast, however above JDK8, javafx has been removed from the JDK and is a separately installable component, which makes app distribution and maitenance hard. But for some reasons I should switch from JDK8 to JDK11 or so, but this is a show stopper now. What could I do, if NIO filechooser is not on the radar yet?
Hanns Holger Rutz
@Sciss
yeah, stay away from JavaFX is the greatest PITA I have ever seen if you need to distribute applications. Swing is fine for that. You could perhaps just register a different file chooser UI for Java 8 and above, based on the original WebLaF but with asynchronous I/O based on NIO.
Mikle
@mgarin

@kovadam69
My original plan was to rework file chooser once project is moved to Java 8+ (or even later one) to incorporate all the NIO improvements, but this might indeed take a long while to get to. And keeping one of the more imprortant and often used components in a bad state is definitely not a good thing. So the best course would be to simply rework it at the current project stage and then improve it a bit further after the minimum supported Java version is increased.

So I've compiled a list of issues related to file chooser in one place: #677
And I'm planning to adress most of them in v1.2.15 update.

This will be a complete revamp of file chooser (and possibly WebFileTree component) so some of the features and APIs might change as a result, especially for WebFileChooserPanel as the core component of the file chooser.


Is there a chance to have it in the near future?

Even though I'm planning it for only one update up the line, it might still take some time. As you've noticed - this year been pretty "dry" on updates, mostly because I've been buried under other projects and due to some other reasons. Work on v1.3.0 is still ongoing and is pretty massive in scale, plus some problems staggered v1.2.14 release as well.

That being said, I've been getting more time to work on WebLaF recently, so there is a good chance that v1.2.14 will be out pretty soon and that I'll start working on v1.2.15 (which might potentially only include file chooser changes). Can't really promise any specific date, but according to current projects - v.1.2.14 should be available early November and v1.2.15 might be available somewhere in early December.


What could I do, if NIO filechooser is not on the radar yet?

As @Sciss mentioned - you can use a different UI implementation, although that might be pretty inconvenient on practice.

I don't really see any other easy/quick solutions to the problem unfortunately. Part of the reason why it was always delayed in the first place is the difficulty of making a proper implementation. Although the issues with the current implementation are definitely on me there, it's one of the oldest chunks of code in WebLaF that I wish would've been written better.

kovadam69
@kovadam69
Hi Mikle! Thanks for the answer, I wait for the update then :)
Hanns Holger Rutz
@Sciss
Trying my luck here. I am encountering since quite a while the situation, that suddenly the app loses keyboard input across the board, it is as if all key listeners are deaf, including for example pressing alt to activate the menu bar, any registered actions etc. This is on Linux with OpenJDK 11. My theory is that this is some kind of keyboard shortcut that I accidentally press and that disables keyboard input, similar to how you can stop vim from receiving keyboard input if you accidentally press Ctrl-S. Only, I haven't found out which keyboard combination causes this, and if there is another shortcut to re-enable keyboard input. Have you ever seen something like that?