Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 28 20:20
    tullisar opened #707
  • Nov 10 20:20
    UlisesRN01 opened #706
  • Oct 26 13:07
    daWoife commented #460
  • Oct 03 21:27
    JLLeitschuh edited #705
  • Oct 03 21:27
    JLLeitschuh edited #705
  • Oct 03 21:26
    JLLeitschuh synchronize #705
  • Sep 23 00:19
    tullisar commented #704
  • Sep 08 22:49
    JLLeitschuh synchronize #705
  • Sep 08 21:48
    JLLeitschuh opened #705
  • Sep 05 01:15
    4SFED edited #704
  • Sep 05 01:07
    4SFED opened #704
  • Sep 05 01:07
    4SFED labeled #704
  • Sep 05 01:07
    4SFED assigned #704
  • Aug 12 14:04
    mgarin commented #702
  • Aug 12 14:04
    mgarin assigned #703
  • Aug 12 14:04
    mgarin labeled #703
  • Aug 12 14:04
    mgarin labeled #703
  • Aug 12 14:04
    mgarin milestoned #703
  • Aug 12 14:04
    mgarin opened #703
  • Aug 11 09:11
    wyj3531 commented #702
kovadam69
@kovadam69
just add with StyleManager your custom skin xml, and you can use it with the StyleId.of("")
Mikle
@mgarin

@kovadam69
You're a bit wrong though, he is creating skin, not an extensions, so he needs XmlSkin not XmlSkinExtension.

@htetaungkhant
As for what the issue is - you have put the style inside the include tag - why? All include does is it imports all styles from another XML skin file. For your case - you want to include the default light skin so you don't have to define all styles for all components. The include you need is:

    <!-- Including WebLaF default skin, will use its style as a base -->
    <include nearClass="com.alee.skin.light.WebLightSkin">resources/web-light-skin.xml</include>

(copy-pasted straight from example)

And simply place your custom progressbar style nearby, you can look at some other skin/extension files available in the project if you aren't sure, like this one: demo-light-extension.xml


The error you see in the log is happening because you have no SLF4J implementation included in your project. It doesn't come with WebLaF by default because everyone have their own logging implementations in their projects and WebLaF uses SLF4J simply as an API for logging, it stil needs the actual implementation. You can read about SLF4J here: http://www.slf4j.org/

The most simple option - use SLF4J simple logger implementation, you can find it on Maven: https://search.maven.org/search?q=g:org.slf4j
Or you can use any other implementation available, for instance Log4j one if you're using it in your project for logging.

Once you have any implementation for SLF4J in your project - you will see the actual errors that occur in the styling with your example.

In WebLaF demo application I'm using SLF4J simple implementation:
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-simple</artifactId>
    <version>1.7.27</version>
</dependency>
Htet Aung Khant
@htetaungkhant
no error when adding that dependency.
Mikle
@mgarin
Well, if you adjusted your XML with the fixes* I mentioned - there shouldn't be one :)

Also, if you're providing a style identifier like this:

<style type="progressbar" id="customProgressbarSkin">

You're creating a custom style based on default style and you will have to apply it manually to each specific progress bar you want to use that style on.

And if you remove the identifier - you will be adjusting the default style and it will apply to all newly created progress bars.

Htet Aung Khant
@htetaungkhant
<skin xmlns="http://weblookandfeel.com/XmlSkin">
    <!-- com.alee.laf.progressbar.WebProgressBar -->
    <id>progressbar.skin</id>
    <class>com.alee.skin</class>
    <supportedSystems>all</supportedSystems>

     <include nearClass="com.alee.skin.light.WebLightSkin">resources/web-light-skin.xml</include>
        <!-- Progress bar -->
        <style type="progressbar">
            <painter>    
                <!-- Progress line -->
                <progressPainter>
                    <decorations>
                        <decoration states="progress">
                            <GradientBackground>
                                <color>16,194,20</color>
                                <color>16,194,20</color>
                            </GradientBackground>
                        </decoration>
                    </decorations>
                </progressPainter>    
            </painter>
        </style>

</skin>
like that?
or
Mikle
@mgarin
Yep
All that is explained in the wiki article though
I'll probably add another one with some step-by-step instructions for creating skin & skin extension later for customizing some component as an example
Htet Aung Khant
@htetaungkhant
Good. :-) :-P
My Progressbar still not changes UI when I create like this.
WebLookAndFeel.install (); WebLookAndFeel.install(ProgressBarSkin.class); JProgressBar jpb = new JProgressBar();
Mikle
@mgarin
Why are you calling install twice though?
Second one obviously does nothing because L&F is already installed.
Just remove the first install call and it should work correctly.
Htet Aung Khant
@htetaungkhant
Wow. Nice. Now, work. Thanks again, Mr. Mikle.
I installed two because I thought first is installing whole WebLaf and second is installing ProgressBarSkin.
Mikle
@mgarin
Nah, it does both. But if you don't specify a custom skin - it simply installs the default one as there always should be an active skin.
Htet Aung Khant
@htetaungkhant
Ok, I know. Today, my project completely finishes. :-)
So, no more give you trouble. :-P
Abu-Abdullah
@Abu-Abdullah
Hi @mgarin, any hint when the next update will be available in maven v1.2.13
Mikle
@mgarin
Hi, unfortunately I've been at home ill since the last Thursday so the update is getting delayed a bit. I'll publish it myself by the end of this week if i'll be back in shape, otherwise I'll aks my colleague to do so (there are still a few minor touches to add before the release).
Abu-Abdullah
@Abu-Abdullah
thank you. I wish you a quick recovery
Abu-Abdullah
@Abu-Abdullah
Hi @mgarin , JScrollPane is not working as expected when defining the policy e.g.
new JScrollPane(JEditorPane, JScrollPane.VERTICAL_SCROLLBAR_AS_NEEDED, JScrollPane.HORIZONTAL_SCROLLBAR_NEVER)
Im expecting this will wrape the text but it did not.
Mikle
@mgarin
Did you try this without WebLaF to see if the result is the same?
I can say for sure that it might not behave as you'd expect with text components and that might be the default behavior.
Abu-Abdullah
@Abu-Abdullah
yes, it is working as expected in older version of the app where it was pure swing base
Mikle
@mgarin
Can you provide a small code example where the issue can be reproduced?
Abu-Abdullah
@Abu-Abdullah
i will look more into forcing text wrape
ok i will try to put sample code
Abu-Abdullah
@Abu-Abdullah
ok, i did very quick test and it seems i was wrong. this issue is from swing and only for other languages than latin. following is a sample. normal English text will work correctly. Arabic is not. but it is not related to webLaF. it is a bug in the backend swing
import com.alee.laf.WebLookAndFeel;

import javax.swing.*;

public class Test extends JFrame
{
    Test()
    {
        JEditorPane p = new JEditorPane();
        p.setText(
                //"sdfsdfsdf sdfsdfsdf sssss s ss s s s s s s s s s ssssssssssssssssssssssss s s ss s sssssssssssssssssssss"
                "للهِ تَعالى- لِتَعْمِيمِ النَّفْع بتِلْكَ الجُهُود المُبارَكة فِي هَذا المَيدَان العَظِيم باشَر القِسْمُ العِلْمِيُّ بِمُؤسَّسةِ الشَّيخِ محُمَّد بنِ صالِحٍ العُثَيمِين الخَيريَّةِ واجِباتِه فِي شَرَفِ الإِعْدادِ والتَّجْهِيز للطِّباعةِ والنَّشْر لإِخْراجِ ذَلِكَ التُّراث العِلمِي؛ إنفاذًا للقَواعِدِ والضَّوابِط والتَّوْجِيهاتِ الَّتِي قَرَّرها فَضيلةُ الشَّيخِ رَحِمَهُ اللهُ تَعالى في هَذا الشَّأْنِ.\n" +
                        "نَسْأل اللهَ تعالى أنْ يَجْعلَ هَذا العَمَلَ خالصًا لِوجهِه الكَريمِ؛ نافِعًا لعِبادِه، وأنْ يَجزِيَ فَضِيلةَ شيخِنا عَنِ الإسلامِ والمسلمِينَ خَيرَ الجزَاء، ويُضَاعِفَ لهُ المثُوبَةَ والأَجْرَ، ويُعليَ دَرَجَتَهُ في المَهْدِيِّينَ، إِنَّه سَمِيعٌ قَرِيبٌ مجُيبٌ."
        );
        WebLookAndFeel.setLeftToRightOrientation(true);
        getContentPane().add(new JScrollPane(p, JScrollPane.VERTICAL_SCROLLBAR_AS_NEEDED, JScrollPane.HORIZONTAL_SCROLLBAR_NEVER));
        setSize(150, 100);
        setVisible(true);
    }

    public static void main(String[] args)
    {
        WebLookAndFeel.install();
        new Test();
    }
}
it was working in older version for some reason. i will check it thoroughly
Mikle
@mgarin

Well, there are a few things with the wrapping - if you try the English variant it will also not wrap once you increase the size of the window and then shrink it, but that's a specific of how text layouting works within text areas, it is really hard to workaround that properly.

But yes, Arabic text doesn't seem to be wrapped at all on newest WebLaF version or with Metal with any Java version.

I'd say if it ever was wrapped before with WebLaF - that was probably at the time when we changed scrollpane layout implementation and there were still some issues floating around it, so the behavior wasn't consistent with default Swing behavior.
Abu-Abdullah
@Abu-Abdullah

Hi @mgarin
Another question. i have this code

searchTree.addCheckStateChangeListener(new CheckStateChangeListener<DefaultMutableTreeNode>()
{
    @Override
    public void checkStateChanged(WebCheckBoxTree<DefaultMutableTreeNode> searchTree, List<CheckStateChange<DefaultMutableTreeNode>> checkStateChanges)
    {
        final java.util.List<DefaultMutableTreeNode> checkedNodes = searchTree.getNodes(CheckState.checked);
        ....

it throws the following exceptio:

java.lang.NullPointerException
    at com.alee.extended.tree.NodesPositionComparator.compare(NodesPositionComparator.java:90)
    at com.alee.extended.tree.NodesPositionComparator.compare(NodesPositionComparator.java:36)
    at java.base/java.util.TimSort.countRunAndMakeAscending(TimSort.java:356)
    at java.base/java.util.TimSort.sort(TimSort.java:220)
    at java.base/java.util.Arrays.sort(Arrays.java:1306)
    at java.base/java.util.ArrayList.sort(ArrayList.java:1720)
    at java.base/java.util.Collections.sort(Collections.java:179)
    at com.alee.extended.tree.DefaultTreeCheckingModel.getNodes(DefaultTreeCheckingModel.java:137)
    at com.alee.extended.tree.WebCheckBoxTree.getNodes(WebCheckBoxTree.java:454)
    at com.alee.extended.tree.WebCheckBoxTree.getNodes(WebCheckBoxTree.java:441)
    at com.myapp.Indexer$2.checkStateChanged(Indexer.java:489)
    at com.alee.extended.tree.DefaultTreeCheckingModel.fireCheckStateChanged(DefaultTreeCheckingModel.java:683)
    at com.alee.extended.tree.DefaultTreeCheckingModel.setChecked(DefaultTreeCheckingModel.java:167)
    at com.alee.extended.tree.WebCheckBoxTree.setChecked(WebCheckBoxTree.java:467)
    at com.myapp.Indexer$22.actionPerformed(Indexer.java:3448)
    at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
    at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
    at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
    at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
    at java.desktop/javax.swing.AbstractButton.doClick(AbstractButton.java:369)
    at java.desktop/javax.swing.AbstractButton.doClick(AbstractButton.java:349)
    at com.myapp.Indexer$8$1.run(Indexer.java:1799)

any hint is appreciated. i cannot build a sample case. it is a bit complicated. but the point is that getNodes(CheckState.checked) throws internal NullPointerException

Mikle
@mgarin
Do you have null nodes in your tree?
Because that's the only reason why that part could throw a NPE
Abu-Abdullah
@Abu-Abdullah

thank you, the exception happens when deleting the nodes. for some reason it is solved by replacing:

WebCheckBoxTree<DefaultMutableTreeNode> searchTree = new WebCheckBoxTree<>(searchRoot);

with

WebCheckBoxTree<DefaultMutableTreeNode> searchTree = new WebCheckBoxTree<>(new DefaultTreeModel(searchRoot));

really no clue what is happening (and i do not recall if the old code was working with swing laf or not) . so please just ignore this case and thank you

Mikle
@mgarin
@Abu-Abdullah
I did check some test cases, but didn't find the NPE yet. Although I'm pretty sure it's a legitimate bug so I've added an issue for it: #633
The reason why you don't get the same exception with DefaultTreeModel is because WebCheckBoxTree uses custom WebTreeModel by default which is somewhat different and might not tolerate some cases that default Swing model does. I'll try to find and fix the bug for the v1.2.14 update.
Mikle
@mgarin
Also, WebLaF v1.2.13 is now available on GitHub: https://github.com/mgarin/weblaf/releases/tag/v1.2.13
And will shortly become available on Maven (once caches are gone).
I wanted to push a few more changes in that release, but it's been taking time so I decided not to delay it even further.
Meanwhile I'm still working on the large performance improvement that is coming in v1.3.0 along with some other changes.
Lukasz S
@strzeszku_gitlab
I found some issues regarding caret position in text fields when using custom fonts. I changed the font to Lato-Regular.ttf which is loaded and registered in GraphicsEnvironment (not a system font). With such font the caret is not positioned properly in all text fields where offset is growing when cursor approaches right margin. It it possible to correct this offset using some WebLaF built in method?
Mikle
@mgarin
@strzeszku_gitlab I'll try it out to see what's happening, but meanwhile - is that behavior consistent with other L&Fs?
As best test sample - Metal Look and Feel. Also behavior might differ in the native look and feel.
Mikle
@mgarin

I've tried the Lato-Regular.ttf (taken from here: https://github.com/google/fonts/blob/master/ofl/lato/Lato-Regular.ttf ) and it works just fine for me. I've tested it on different JDK versions (6, 8, 9, 11 and 13) and different L&F (Metal and WebLaF) under Windows OS - behavior seems to be exactly the same across all tests - caret is properly positioned on the text in JTextField with both short and long texts at any index in that text.

So I'll need more details about cases when you see the issue:

  • Java version you're running
  • OS type/version
  • WebLaF version you're using
  • Small code example representing the issue
Lukasz S
@strzeszku_gitlab
I run app on mac os 10.15.5 with oracle jdk 1.8u252 and adopt openjdk 1.8u252, WebLaF 1.2.13. Tried to change component font using
Font fontLatoRegular = loadFontLatoRegular();
FontUtils.replaceFontUIResource(jTextField2, fontLatoRegular.deriveFont(13f));
and
WebLookAndFeel.globalTextFont =latoFont;
The second one method before WebLookAndFeel.install();
Mikle
@mgarin

This part:

Font fontLatoRegular = loadFontLatoRegular();

Doesn't really tell much unfortunately, how exactly is the Font created?
And do you see the same issue with the font I've linked above?

Also, does that issue appear for you under MetalLookAndFeel?
Lukasz S
@strzeszku_gitlab
@mgarin
public static final Font loadFontLatoRegular() {
try {
InputStream fontStream = FontTests.class.getResourceAsStream("/resources/fonts/Lato/Lato-Regular.ttf");
Font font = Font.createFont(Font.TRUETYPE_FONT, fontStream);
return font.deriveFont(13f);
} catch (IOException | NullPointerException | FontFormatException ex) {
java.util.logging.Logger.getLogger(FontTests.class.getName()).log(java.util.logging.Level.SEVERE, null, ex);
return null;
}
}
I must load the font from resources not as a system font. I will check the same app on windows 8.1 machine in few minutes.
Mikle
@mgarin

Yep, exactly the same code I've used in my test class:

public class FontTest
{
    public static void main ( final String[] args )
    {
        SwingUtilities.invokeLater ( new Runnable ()
        {
            @Override
            public void run ()
            {
                try
                {
                    UIManager.setLookAndFeel ( WebLookAndFeel.class.getCanonicalName () );
                    // UIManager.setLookAndFeel ( MetalLookAndFeel.class.getCanonicalName () );

                    final Font font = Font.createFont (
                            Font.TRUETYPE_FONT,
                            FontTest.class.getResourceAsStream ( "Lato-Regular.ttf" )
                    ).deriveFont ( 16f );

                    final JFrame frame = new JFrame ();
                    frame.setLayout ( new FlowLayout () );

                    final JTextField textField = new JTextField ( 50 );
                    textField.setFont ( font );
                    frame.add ( textField );

                    frame.setSize ( 800, 600 );
                    frame.setLocationRelativeTo ( null );
                    frame.setDefaultCloseOperation ( WindowConstants.EXIT_ON_CLOSE );
                    frame.setVisible ( true );
                }
                catch ( final Exception e )
                {
                    e.printStackTrace ();
                }
            }
        } );
    }
}

I recommend you to try this small example and see if the same issue occurs or not, once with WebLaF and once with the MetalLookAndFeel.

If it doesn't appear on this example - it might have something to do with other settings in your application.
If it does - then it could be a Java issue on Mac OS, especially if it appears for you on both L&Fs.

Lukasz S
@strzeszku_gitlab
@mgarin the same issue occurs with your example both with WebLaF and Metal, but only on Mac OS. There is no such issue on Windows 8.1 without hidpi display. Could it have something in common the hidpi display? I have no older mac to check how it looks on fullhd display.
Mikle
@mgarin

I'd say it's a 50/50, it might be caused by hidpi display, but on hidpi I would expect caret in text field to be visually offset by a fixed amount of pixels. The fact that offset increases with larger index means that there is a difference in caret position calculation and font rendering - caret position calculation either uses old font or has some deeper issues.

If it's the same on MetalLookAndFeel that means it's just a general Java issue, potentially with particular font (or all non-system/custom fonts?) - hard to tell really.

After a quick search on the matter I found this issue: https://bugs.openjdk.java.net/browse/JDK-8014069
It does seem to be resolved long ago though, but it sure does resemble your description of the problem.

Overall - I can't really do anything about font-related issues like this one because both font rendering and font-related calculations aren't done by L&F code and are simply retrieved from public APIs (like FontMetrics for instance). There could definitely be cases where WebLaF is at fault, but that would usually be reproducible against other L&Fs and would mostly cause the same issues across different OS versions.