Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:44
    mgarin commented #595
  • 08:44
    mgarin commented #595
  • 08:42
    mgarin commented #595
  • Jan 15 12:19

    mgarin on master

    Project - README.md - Slightly … (compare)

  • Jan 15 12:09
    mgarin updated the wiki
  • Jan 15 12:08
    mgarin updated the wiki
  • Jan 15 12:08
    mgarin updated the wiki
  • Jan 15 12:03
    mgarin updated the wiki
  • Jan 15 11:43
    mgarin updated the wiki
  • Jan 14 09:34

    mgarin on master

    Project - README.md - Added mor… (compare)

  • Jan 13 14:02
    mgarin commented #604
  • Jan 13 14:01
    mgarin demilestoned #604
  • Jan 13 14:01
    mgarin milestoned #604
  • Jan 13 14:01
    mgarin commented #604
  • Jan 13 14:00
    mgarin labeled #604
  • Jan 13 14:00

    mgarin on master

    Styling [ #604 ] - WebDialog.ja… (compare)

  • Jan 13 13:56

    mgarin on master

    Switched `master` version to `1… (compare)

  • Jan 13 13:52
    mgarin commented #604
  • Jan 13 13:48
    mgarin milestoned #604
  • Jan 13 13:48
    mgarin labeled #604
Mikle
@mgarin

Option 1 causes error: package StyleId does not exist, option 2 causes error: cannot find symbol... StyleId

You seem to have some issues with dependencies in your project, can't really say what is exactly wrong, but that is certainly not something caused by WebLaF. As long as you have weblaf-ui and weblaf-core modules attached to your project (and all dependencies/libraries those require) it should work correctly.

Also - where can I find a list of the style strings (e.g., "attached-north")?

Either in StyleId class/source:
https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/managers/style/StyleId.java

Or in component XML style files, like the button.xml:
https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/skin/dark/resources/button.xml

phillipcurtsmith
@phillipcurtsmith
Thanks, figured it out, screwed up my import of ui and core. Thanks for your help.
Mikle
@mgarin
No problem :)
Regarding the styles - I plan to eventually upgrade the demo app to be more representative of what is available in default package.
Basically some way to check out how existing styles for components look like and try them out with different component settings.
Hanns Holger Rutz
@Sciss
Hi there and happy new year! There is a tiny issue, I think since long time, with tooltip rendering in the wrong height, so that the text exceeds the top border. Might be related to them going into their own window when exceeding the parent window's bounds. Observed on Linux. Example (also the triangle has a slightly off position):
tut-paulstretch-fscape-in-folder.png
Haven't seen a directly corresponding issue in the tracker, so wanted to raise it here first.
Mikle
@mgarin
It looks like the border is there, but it's just totally wrong, i'll have a look at it and fix it. Also I'm planning to revamp these tooltips (internally, possibly no API changes), but that will be coming later. There are some issues with them, including lack of proper styling support and just overall jankyness of the code (probably the source of any issues appearing on those, including this one).
Mikle
@mgarin

@sciss
Ok, I've finally got to check the issue with the tooltip and I couldn't really reproduce it on any system/JDK version.

And I also noticed one weird thing about the screenshot you've shown - these custom tooltips do not ever go beyond visible window borders as they're positioned on the glass pane which is normally has root pane bounds (in natively decorated frame) or decoration bounds (in custom decorated frame), they do not use separate window to display themselves. So I'm not really sure how it manages to be outside of the frame bounds in your example.

So preferably I'll need a small example that showcases the problem, JDK/OS versions where it is visible and WebLaF version you're using.

Hanns Holger Rutz
@Sciss
@mgarin ok, thanks for checking and sorry if it's not immediately reproducible; I will try to distill a simple example.
Mikle
@mgarin
No problem, it just seems that it might be an OS or JDK version -related issue.
Or even some specific use case.
On the bright side - I've found and fixed an issue with custom window decoration while trying to reproduce the tooltip bug :)
kovadam69
@kovadam69
Hi Mikle! Could this bug have cosen problems with decorated dialogs? I tried in the morning the new 1.2.12 snapshot, and my dialog had nothing else just a header (the complete root pane was missing). Also no decoration did work, instead of the decorated header, it had system header decoration.
Mikle
@mgarin
It could have caused a bunch of different issues depending on JDK & OS version, including the one you described, but hard to say for sure. You can try newest snapshot (it is already available) to see if it fixes the problem for you.
Hanns Holger Rutz
@Sciss

Ok, I have a reproducer:

import com.alee.laf.WebLookAndFeel;

import javax.swing.Box;
import javax.swing.BoxLayout;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JMenu;
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
import javax.swing.JPanel;
import java.awt.EventQueue;

public class TooltipTest {
    public static void main(String[] args) {
        EventQueue.invokeLater(() -> {
            WebLookAndFeel.install();
            final JFrame f = new JFrame("Test");

            final JMenuBar  mb      = new JMenuBar();
            final JMenu     mFile   = new JMenu("File");
            final JMenuItem mNew    = new JMenu("New");
            mFile.add(mNew);
            mb.add(mFile);
            f.setJMenuBar(mb);

            final JPanel p = new JPanel();
            p.setLayout(new BoxLayout(p, BoxLayout.X_AXIS));
            p.add(Box.createHorizontalStrut(50));
            final JLabel lbNumUGens  = new JLabel("tool-tip");
            lbNumUGens.setToolTipText("UGens");
            p.add(lbNumUGens);
            p.add(Box.createHorizontalStrut(50));

            f.setResizable(false);
            f.getContentPane().add(p);
            f.pack();
            f.setVisible(true);
        });
    }
}

The tool-tips get the wrong bounds after one has used the menu-bar. Tested with JDK 8 and JDK 11 on Linux. So something happens internally after the menu-bar is made opened the first time.

Before using the menu:
Screenshot from 2020-01-07 15-27-34.jpg
after using the menu:
Screenshot from 2020-01-07 15-27-41.jpg
Mikle
@mgarin
It seems that tooltip reuses popup window that was used for menu (and shape simply doesn't get reset).
Although that might have something to do with the fix i've just pushed before checking this.
You're working with v1.2.12 snapshot version or some previous one?
Hanns Holger Rutz
@Sciss
1.2.11 release
Mikle
@mgarin
Then it is probably unrelated, the fixed issue was introduced recently in snapshot version only.
Mikle
@mgarin
I have a fix for this, just doing some extra testing because it can affect a lot of other stuff. I've also added an issue in tracker for reference: #602
Mikle
@mgarin
I've pushed the fix, it will be available in v1.2.12 snapshot shortly.
I'll be working on the lazy styles initialization next week or two and it will probably be the last change for v1.2.12 before the release (not counting any possible bugfixes).
Versioning might also be changed starting from this update, but I haven't decided on that one yet, will see close to the release.
Hanns Holger Rutz
@Sciss
Thanks. I'll wait for the release, as it is not a crucial problem.
Mikle
@mgarin

Important note about upcoming updates -
Starting after the next update I'm going to adjust versioning, so here is a small explanation how it will work:

  1. Current update I'm working on - v1.2.12 - will be released soon with the changes existing in master branch and will keep v1.2.12 version.

  2. Next update will be v1.3.0 - it will include only changes related to #595 and bugfixes and will be the first update using proper approach to versioning that I'm going to try. Once it is released I will create v1.3.0 branch based on the update revision so it can be used in the future for patching bugs and releasing smaller v1.3.x updates in case those are needed. Similar approach will be used for all future updates like v1.4.0, v1.5.0, ..., v2.0.0 etc.

  3. Next will be v1.4.0 update which will include changes for the issues that were not implemented in v1.2.12 yet. Although list is pretty big and some changes will most probably be moved to next versions. Generally I will do my best to implement as many planned changes as possible within one update, but at the same time I will not stretch development of each update for longer than 1~2 months. Although I will prioritize features that will be cut from the current update and moved to next update in that next update. So if something that you were waiting for doesn't make it into the update - it doesn't necessary mean that it will take longer to be implemented.

  4. Next update will be v1.5.0 which was previously visible on the projects page as v1.2.13 update. Nothing really changed for that one, I simply renamed it to match the versions that will be released before it.

  5. Last update I want to mention is one that is currently named as v1.9.0 on the projects page and was previously named v1.3.0 - it was renamed similarly to v1.2.13 and nothing really changed for it either. This will be the last big update before I will be moving to v2.0.0 and JDK8+ support.

The main reason behind the change is simple - I will be able to properly push bugfixes in patch versions for each major/minor release if necessary so you don't have to wait for the fixes for 1~2 months (for another major/minor update). And it will also be more correct to have major/minor versions to contain new features and improvements instead of having those in iterative patch versions.


TL;DR:
v1.2.12 -> v1.2.12 (ready) + v1.3.0 (in work) + v1.4.0 (tbd)
v1.2.13 -> v1.5.0
v1.3.0 -> v1.9.0
v2.0.0 -> remains as it is now
And each major/minor release will have it's own branch starting with v1.3.0 for quick bugfixes (v1.3.1, v1.3.2, etc)

Mikle
@mgarin
@Sciss
I have released v1.2.12 update, it should become available in Maven shortly (between 10m and 1h from now).
It contains the fix for the tooltip, some other issues and some internal refactoring I've made in preparation to the init performance improvements.
kovadam69
@kovadam69

Hi Mikle! I just tried v1.2.12-20200109.104001-14, but dialog and frame decoration is still not good. The content seems now to be OK, but the header is still Window Manager decorated instead of WebLaf. I have set the

        JDialog.setDefaultLookAndFeelDecorated(true);
        JFrame.setDefaultLookAndFeelDecorated(true);

It was working with v 1.2.11.

Mikle
@mgarin
This might be a different issue though, I'll look into that.
How do you create a decorated dialog/frame?
Can you try specifying decorated StyleId instead of the static settings you've mentioned above? - this might solve the issue for you for now.
Specifically StyleId.dialogDecorated for WebDialog or StyleId.frameDecorated for WebFrame.
Generally I recommend using StyleId when possible as it might have a better performance in some cases.
kovadam69
@kovadam69
this is how I create the loginform for example: final WebDialog loginForm = new WebDialog(StyleId.dialogDecorated, (Window) null, TranslationProvider.getLabel(LabelConstants.LOGIN_TITLE));
Mikle
@mgarin
And dialog stays with native decoration in that case for you?
kovadam69
@kovadam69
yes, the header (close btn, etc) is the system native decoration. The dialog inside, buttons, text, etc. are correct
Mikle
@mgarin
Does this example result in native decoration for you?
public class DialogTest
{
    public static void main ( String[] args )
    {
        SwingTest.run ( new Runnable ()
        {
            public void run ()
            {
                final WebDialog loginForm = new WebDialog ( StyleId.dialogDecorated, ( Window ) null, "Sample dialog" );
                loginForm.setSize ( 500, 500 );
                loginForm.setLocationRelativeTo ( null );
                loginForm.setVisible ( true );
            }
        } );
    }
}
I've tried this under Windows 8/Windows 10/Ubuntu 18 and JDK6/8/11/13 - all work as expected.
Although I tried it on the release v1.2.12 version (which uses exactly the same code as the snapshot you mentioned though).
Mikle
@mgarin
If this example works properly for you - there must be something else in your code that prevents decoration from appearing.
Mikle
@mgarin
I've found the cause of that issue - it happens only when JDialog.setDefaultLookAndFeelDecorated(true); is used.
It causes internal StyleId clash and required update is ignored instead of being applied to the underlying JRootPane.
I have made a fix and will push it under v1.3.0-SNAPSHOT, but it will be quite hard to release it before I'm done with v1.3.0 changes now.
Mikle
@mgarin
I'll push the fix a bit later, gonna make sure this issue never appears again.
Overall it is caused by some spaghetti code related to window decoration initialization potentially coming from two different settings.
kovadam69
@kovadam69
So if I remove the setDefault.... it should work like before?
yess, it's working... I remove the these setDefault... lines from code.
although it seems if I remove the "setDefault..." lines, the WebOptionPane.showXXXX seems to come without decoration
kovadam69
@kovadam69
the sample code you provided runs fine, it has decoration properly
if I add JDialog.setDefaultLookAndFeelDecorated(true);, the dialog header is changed to system decoration
https://imgur.com/C28sRyO
using this code
public static void main ( String[] args )
    {
        SwingTest.run (new Runnable ()
        {
            public void run ()
            {
                NativeFonts.setUseNativeFonts ( false );
                WebLookAndFeel.install();
                JDialog.setDefaultLookAndFeelDecorated(true);

                final WebDialog loginForm = new WebDialog ( StyleId.dialogDecorated, (Window) null, "Sample dialog" );

                loginForm.getContentPane().add(new WebButton("Press me", (e) ->
                {
                    WebOptionPane.showConfirmDialog(loginForm, "confirm", "confirm", WebOptionPane.YES_NO_OPTION);
                }));

                loginForm.setSize ( 500, 500 );
                loginForm.setLocationRelativeTo ( null );
                loginForm.setVisible ( true );
            }
        } );
    }
https://imgur.com/bgKhHCA
using this code
public static void main ( String[] args )
    {
        SwingTest.run (new Runnable ()
        {
            public void run ()
            {
                NativeFonts.setUseNativeFonts ( false );
                WebLookAndFeel.install();

                final WebDialog loginForm = new WebDialog ( StyleId.dialogDecorated, (Window) null, "Sample dialog" );

                loginForm.getContentPane().add(new WebButton("Press me", (e) ->
                {
                    WebOptionPane.showConfirmDialog(loginForm, "confirm", "confirm", WebOptionPane.YES_NO_OPTION);
                }));

                loginForm.setSize ( 500, 500 );
                loginForm.setLocationRelativeTo ( null );
                loginForm.setVisible ( true );
            }
        } );
    }
Mikle
@mgarin
Regarding option pane - yes, it will be natively decorated without the static settings (which cause issues in the normal dialogs/frames).
Unfortunately you'll need the fix to properly decorate both options.
Mikle
@mgarin
Although there could also be a possible workaround until the next update - use JDialog/JFrame instead of WebDialog/WebFrame - they will work correctly and have custom decoration with JDialog and JFrame static settings set to true.
kovadam69
@kovadam69
OK, no problem it's not an issue or blocker for me, however change to JDialog/JFrame everywhere I create a dialog or frame would be much more work. We can live now with this kind of "bug" until it's fixed.
Mikle
@mgarin
I've opened issue #604 for this problem.
And I also pushed the fix, it will shortly be available in v1.3.0 snapshot version.
Mikle
@mgarin
@kovadam69
Generally speaking you can use the latest v1.3.0 snapshot - it should fix everything for you.
It basically contains only that fix and nothing else so far.
kovadam69
@kovadam69
I will check it, thanks!