Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 20 19:56
    mgarin commented #662
  • Jan 20 19:56
    mgarin milestoned #662
  • Jan 20 19:56
    mgarin labeled #662
  • Jan 20 19:56
    mgarin assigned #662
  • Jan 19 00:35
    tullisar edited #662
  • Jan 19 00:34
    tullisar opened #662
  • Dec 21 2020 16:56

    dependabot[bot] on maven

    Bump xstream from 1.4.12 to 1.4… (compare)

  • Dec 21 2020 16:56
    dependabot[bot] labeled #661
  • Dec 21 2020 16:56
    dependabot[bot] opened #661
  • Dec 14 2020 14:27

    dependabot[bot] on maven

    (compare)

  • Dec 14 2020 14:27
    dependabot[bot] commented #656
  • Dec 14 2020 14:27
    mgarin closed #656
  • Dec 11 2020 15:28
    mgarin closed #642
  • Dec 11 2020 15:28
    mgarin commented #642
  • Dec 11 2020 15:25
    mgarin demilestoned #642
  • Dec 11 2020 15:25
    mgarin labeled #642
  • Dec 11 2020 15:23
    mgarin commented #642
  • Dec 11 2020 07:12
    christianheilmann commented #415
  • Dec 11 2020 07:09
    christianheilmann commented #415
  • Dec 09 2020 17:39
    mgarin commented #415
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.

Mikle
@mgarin

What I could recommend doing - try the same example with newer Java versions (9+) and see if the same issue appears there. If newer Java version fixes it - it might be worth switching your application over to newer version if it is possible.

Alternatively - the issue seem to be caused by custom font's size being different from the default font size of the component. Maybe it would work correctly if you use the same font size as the component has by default for your custom font. That's just an idea for a possible workaround.

Also if the issue is still there for you on latest Java 8 updates or even newer Java versions - it might be worth submitting a JDK bug report. I've found quite a few JDK bugs over the years and submitted most of them. Some have been fixed since and some unfortunately are still not resolved, so that could take a long while. Also fixes for reported bugs will most probably only be available on newer Java versions.

Lukasz S
@strzeszku_gitlab
@mgarin switching to java 11 resolves the problem, but will take lot of time to switch whole the app. For java 8 I have to install the font in system to resolve the problem. Simple registering in graphicalEnvironment in main does not help.
Mikle
@mgarin

Well, unfortunately I can't really do anything about it.
Core Java issues always suck and you just have to deal with them in the least "painful" way.

Does aligning the custom font's size with the default component font's size help?

kovadam69
@kovadam69
Hi! Short question. Is it possible to have in WebTable multi-line groupped column headers?
Mikle
@mgarin

@kovadam69 Right now - only if you use some 3rd-party solution or make one yourself. WebLaF currently provides close to none features on top of the basic JTable, so functionality-wise WebTable is pretty much the same as JTable with just a few convenience methods added on top.

We did have a similar task for one of our internal projects - to make a useable multi-line table header - but I wasn't the one working on it and the final solution was quite sloppy and only worked for that particular case, so it didn't make it into WebLaF in the end.

I do plan to eventually expand JTable to support multi-line header, cells merging, better sorting and some other features I really want to see myself, but it all requires quite an extensive rework of the basic table implementation (both UI and component), so that will most probably be a completely separate new component - something like WebExTable - and it will take a substantial amount of time to add, which I probably won' have this year.

There are already quite a few issues added for JTable: https://github.com/mgarin/weblaf/issues?q=is%3Aissue+is%3Aopen+table
I'll make a summary issue now that will list all the planned improvements that are split into separate issues and which you can track.

kovadam69
@kovadam69
@mgarin Thanks! I will wait for it than, unless I really need one, then I have to implement it myself. I already found some implementation, but it has to be fixed, since they miscalculate the cell width (cell width does not match column width) and also they are not draggable, clickable, etc.
kovadam69
@kovadam69
Hi Mikle! I faced a problem between 1.3.0 and 1.2.14. Recently I discovered, that 1.2.14 is newer and contains more fix, than 1.3.0, so I switched back to 1.2.14, however now I faced some problem with WebStyledLabel in Table Header. See image attached. For some reason with 1.2.14 it adds end ellipsis though the text would fit into the cell without any problems. What can I do about it? Thanks!
https://imgur.com/1G1Cxc6
The upper image is with 1.3.0 and the lower with 1.2.14... It's a bit annoying to have ... at the end.
Mikle
@mgarin

@kovadam69
If you meant 1.3.0 snapshot - it have been purely experimental and I wouldn't recommend using it.
Currently latest version is 1.2.13, and latest snapshot is 1.2.14.

There have been some important changes done to WebStyledLabel in one of 1.2.14 commits: mgarin/weblaf@0a39e8c
They might have affected the table title rendering, but I'll have to double-check that.

Judging by the screenshots - table header size calculations remained the same, but label doesn't fit into the available width anymore.
Can you give that specific title text or does this issue appear on any text?
Is this text containing HTML by any chance?
If it is an HTML with <br> tag, can you try using {br} (since renderer is a WebStyledLabel this should work) instead to see if it fixes the issue?

kovadam69
@kovadam69
It's simple text, there is no html or line break, wrapping is done by the WebStyledLabel. The text is just any simple two word text (like Szállító kelte or Teljesítés dátuma or Fizetési határidő or ÁFA teljesítés dátuma, etc.). Previously it also broke 3 word texts into 3 lines, now it also uses ... in the 2nd line, without braking it into 3 lines.
kovadam69
@kovadam69
Something is totally wrong with WebStyledLabel wrapping:
https://imgur.com/ysFSnQ0
this was produced by this code:
        WebLookAndFeel.install();

        final WebMemoryBar memoryBar = new WebMemoryBar ();
        memoryBar.setPreferredWidth ( 200 );

        WebPanel panel = new WebPanel();
        panel.setPreferredSize(400, 28);

        WebStyledLabel label = new WebStyledLabel();
        label.setWrap(TextWrap.word);

        label.setText("Asdfasdf 12345678-12345678-12345667 AA123456781234556767");
        label.setBoldFont();

        panel.add(label);

        TestFrame frame = TestFrame.show(5, false, panel, memoryBar);
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!