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.
<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>WebLookAndFeel.install ();
WebLookAndFeel.install(ProgressBarSkin.class);
JProgressBar jpb = new JProgressBar();
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();
}
}
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.
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
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
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.
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.
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
Font fontLatoRegular = loadFontLatoRegular();
FontUtils.replaceFontUIResource(jTextField2, fontLatoRegular.deriveFont(13f));
and
WebLookAndFeel.globalTextFont =latoFont;
The second one method before WebLookAndFeel.install();
MetalLookAndFeel?
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;
}
}
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.
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.
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.