Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 15 14:08
    mgarin unlabeled #461
  • Aug 15 14:08
    mgarin unlabeled #461
  • Aug 15 14:08
    mgarin unlabeled #461
  • Aug 15 14:07
    mgarin edited #476
  • Aug 15 14:06
    mgarin commented #461
  • Aug 15 14:05
    mgarin labeled #523
  • Aug 15 14:05
    mgarin milestoned #523
  • Aug 15 14:05
    mgarin labeled #523
  • Aug 15 14:05
    mgarin assigned #523
  • Aug 15 14:05
    mgarin opened #523
  • Aug 15 12:43

    mgarin on master

    Demo - DemoApplication.java - S… (compare)

  • Aug 15 09:24
    mgarin updated the wiki
  • Aug 15 09:20
    mgarin updated the wiki
  • Aug 15 09:20
    mgarin updated the wiki
  • Aug 15 08:51
    mgarin updated the wiki
  • Aug 15 08:43
    mgarin updated the wiki
  • Aug 15 08:35
    mgarin commented #522
  • Aug 15 08:32
    mgarin commented #522
  • Aug 15 08:18
    mgarin labeled #522
  • Aug 15 08:18
    mgarin assigned #522
Mikle
@mgarin
I'll make a quick fix for this into styling branch.
kovadam69
@kovadam69
OK, thanks! Now I'm using the workaround, but I kept also the old code, which used the TableHeader as the reference component, so after the fix build is out in the repo I will try with the old code.
Glad you understood, despite I messed up the screen numbering :D (#0-#1 vs. #1-#2)
Mikle
@mgarin

To be honest, I got it already at the part where you mentioned SystemUtils.getDeviceBounds method first time and the fact it was used in dual-screen setting :)

I just need to make sure I won't break anything while fixing this particular case as the base method that causes issues - getBoundsOnScreen - is used in multiple places. I will probably add a flag into it to make it clear whether or not only visible bounds are used because these are not always the ones I might need, although for now it seems to be fine for most use cases.

kovadam69
@kovadam69
ah, ok :D
take your time, it's not urgent, since I made a workaround, and now it's fine, using the scrollpane.
Mikle
@mgarin
I will add it soon as it actually affects a few other things that would misbehave in some particular cases. It's just that those cases are quite rare and it might even be hard to notice the issue as it is not represented as clearly as in your case with popover positioning.
Mikle
@mgarin
I've pushed the change and some followup fixes that were needed after testing it for a bit. It should correctly determine the screen now, but all positioning should still be using absolute coordinates to avoid confusion when dealing with custom popup/popover positioning. I will be pushing some major popover changes later and I will add some more improvements towards how its position can be provided/configured, but for now it should mostly be the same minus the bug :)
New version will be available in snapshot repo in 10~15 minutes.
kovadam69
@kovadam69
Hi Mikle! I will try the fix of the popover positioning some time later, however now I have a different question. The WebFileChooser was pretty slow when browsing huge directories or network directories and you said it is because it does not use NIO. Did you manage to change that, or it is still that slow? Thanks!
Mikle
@mgarin

Haven't changed it yet and I doubt there can be any major performance changes as long as currently developed WebLaF version supports JDK 6. Unfortunately there are only a few minor improvements possible with older IO and they won't really change much in terms of overall chooser performance in the cases mentioned. I might look into making all of the IO related operations asynchronous to avoid UI being visibly stuck, but that alone will require quite a lot of work and it won't really change the fact that any network files are loaded REALLY slow and that large folders will take a while to load (compared to any native or NIO-based choosers).

I do have plan to move on to newer JDK versions with later WebLaF releases, maybe I will even stick with edge JDK versions (or at LTS versions at most) due to changes in JDK releases and Oracle policy. In either case - one of the first things I will be changing upon moving to newer JDK version is revisiting all older IO usages and replacing them with appropriate NIO implementations. That will surely bump chooser performance, especially for the cases with large and network folders.

I can't say for sure when exactly this will happen. First of all I need a stable and polished WebLaF version for JDK6+, then I can separate newer JDK only supporting version and work primarily on it.

kovadam69
@kovadam69
Ah, OK, thanks! Now I'm using the file chooser from the JavaFX library, since it uses the native OS file chooser, so it's really fast. However since Oracle changed the usage condition on the JRE/JDK, switching to OpenJDK will make JavaFX usage a bit complicated, so this is why I asked.
Charlie Doern
@cdoern
Hi! I just have a quick clarifying question on purchasing a license. If i do not purchase a license but I open source the code that is allowed correct? It would not be allowed if I did not make my code open source, I would then have to buy a license, right? Sorry if this is a basic question I was just trying to use the library and noticed some warnings when running my code about licenses and decided to ask here!
Mikle
@mgarin

@cdoern It basically comes down to whether your project is commercial or not, to put it simple - whether you will be making money out of your project that uses WebLaF or not. If you are working on a commercial project, whether it is open-source or not, - you need to purchase either of the two available licenses. If you are not working on a commercial project - you are free to use WebLaF under GPLv3 open-source license terms.

Code disclosure requirement only comes from GPLv3 license and is only applicable if you are sharing your work with someone. So for instance if you are making a project for yourself and not going to share it with anyone - you don't need to purchase anything and you don't need to disclose the source code. Once you start sharing/distributing your software to anyone - source code must also be made available, at least to those who you are distributing your software to.

Regarding the warnings you got - it is certainly not WebLaF, maybe some different commercial library you are using. WebLaF doesn't have any license-related code integrated, so any version of it you can download from WebLaF site, GitHub project page or Sonatype snapshot repo should work perfectly fine and should never prompt you with any license-related warnings/popups/shutdowns or whatever else that is usually included in demo-like versions of other commercial libraries. Also both commercial and free versions of the library are basically identical on the code side, the only small difference are the license files included in distribution.

kovadam69
@kovadam69
Hi Mikle! Just a short question not even related to weblaf, just Swing, but since you are really experienced with Swing and I did not found any good resource on net I dare to ask you: is there a good way to determine if a component is visible to a user? What I want to achieve: for example I have several fields on a tabbed pane on different tabs. The fields are validated whether the input is valid when the user presses the "Save" button. For invalid fields I display a BaloonTip to show the user which field has validation problems. However if the field is not visible (because it is on a hidden tab, or outside of the scrollpane visible area, etc). The user has no idea why the save is not working. For this I found out I will display also a WebNotification using your NotificationManager framework. However if there is a lot validation error, a lot message are displayed. So I would like to achieve, that only components message should be displayed, which are not visible to the user. So do you know some method how I could find out whether a JComponent is visible to the user or not? Thanks in advance for your time and help!
Mikle
@mgarin

I'm pretty sure I had an implementation of a method that checks such visibility conditions, but can't really find it. Although I did find one method that might help - CoreSwingUtils.getBoundsOnScreen(...) - if you pass your component along with true for visibleOnly argument you will always receive component bounds that either have some width/height if it is actually visible on screen, including checks for scrolls but not including checks for any overlaying windows as that is kinda hard to do without diving into native stuff. In case component is not visible it will simply return zero width and height. Although that method does not account for component being displayed and will throw an exception if component is not showing at the moment. It can be easily checked before though, so something like this should work for you:

    /**
     * Returns whether or not specified {@link Component} is actually visible on screen.
     * Note that this method does not account for any other windows that may overlay current one, that needs to be checked separately.
     *
     * @param component {@link Component} to check visibility on screen for
     * @return {@code true} if specified {@link Component} is actually visible on screen, {@code false} otherwise
     */
    public static boolean isVisibleOnScreen ( final Component component )
    {
        final boolean visible;
        if ( component.isShowing () )
        {
            final Rectangle bounds = CoreSwingUtils.getBoundsOnScreen ( component, true );
            visible = bounds.width > 0 && bounds.height > 0;
        }
        else
        {
            visible = false;
        }
        return visible;
    }

I've added this method into CoreSwingUtils as it might be useful in future, so you can use it with the later updates.

Other windows that might overlay current one are not accounted for in this method for a few reasons:

  • It is close to impossible to account for native windows of other applications, will require some wonky native API usage and will not result in anything good
  • It is possible to account for windows of current application, but simply using window bounds can be innacurate - for instance due to windows being partially transparent
  • Such check would only work in specific context as sometmes you might not want it at all, so better not to do it in the first place in this method but instead do it outside when needed
I tried the method from above with a small example and it seem to work the way you want it to:
public class VisibilityExample
{
    public static void main ( final String[] args )
    {
        SwingUtilities.invokeLater ( new Runnable ()
        {
            @Override
            public void run ()
            {
                WebLookAndFeel.install ();

                final JTabbedPane tabbedPane = new JTabbedPane ();

                final JPanel firstPanel = new JPanel ( new VerticalFlowLayout ( 0, 50, true, false ) );
                for ( int i = 0; i < 200; i++ )
                {
                    firstPanel.add ( new JButton ( "1 tab -> Sample button #" + ( i + 1 ) ) );
                }
                final JScrollPane firstScroll = new JScrollPane ( firstPanel );
                firstScroll.setPreferredSize ( new Dimension ( 500, 400 ) );
                tabbedPane.addTab ( "First", firstScroll );

                final JPanel secondPanel = new JPanel ( new VerticalFlowLayout ( 0, 50, true, false ) );
                for ( int i = 0; i < 200; i++ )
                {
                    secondPanel.add ( new JButton ( "2 tab -> Sample button #" + ( i + 1 ) ) );
                }
                final JScrollPane secondScroll = new JScrollPane ( secondPanel );
                secondScroll.setPreferredSize ( new Dimension ( 500, 400 ) );
                tabbedPane.addTab ( "Second", secondScroll );

                final JButton tips = new JButton ( "Show tooltips" );
                tips.addActionListener ( new ActionListener ()
                {
                    @Override
                    public void actionPerformed ( final ActionEvent e )
                    {
                        for ( int i = 0; i < firstPanel.getComponentCount (); i++ )
                        {
                            showTooltip ( ( JButton ) firstPanel.getComponent ( i ) );
                        }
                        for ( int i = 0; i < secondPanel.getComponentCount (); i++ )
                        {
                            showTooltip ( ( JButton ) secondPanel.getComponent ( i ) );
                        }
                    }

                    private void showTooltip ( final JButton button )
                    {
                        if ( CoreSwingUtils.isVisibleOnScreen ( button ) )
                        {
                            TooltipManager.showOneTimeTooltip (
                                button,
                                new Point ( button.getWidth () / 2, button.getHeight () ),
                                button.getText ()
                            );
                            System.out.println ( "Displayed tooltip for: " + button.getText () );
                        }
                    }
                } );

                TestFrame.show ( 5, false, tabbedPane, tips );
            }
        } );
    }
}
Results in tootips for only visible components:
image.png
And log for the display:
Displayed tooltip for: 2 tab -> Sample button #48
Displayed tooltip for: 2 tab -> Sample button #49
Displayed tooltip for: 2 tab -> Sample button #50
Displayed tooltip for: 2 tab -> Sample button #51
Displayed tooltip for: 2 tab -> Sample button #52
I've pushed this method in styling branch mgarin/weblaf@ec2e395
New snapshot build with it should also be available in 15-20 minutes
kovadam69
@kovadam69
Mikle! Great, thanks! I do not really care about native windows or different windows hiding components, it's the user's fault, if the program is hidden partly by other windows. It was really just to check, whether the component is really visible on the user's view within the app (like not hidden on a different tab, or out of scrollpane's viewport, etc.). This is totally OK for me. Thank you for taking time to investigate this, I know you have million other tasks.
kovadam69
@kovadam69
I tried the new LIB and it's working like I expected. Thank you again!
Mikle
@mgarin
No problem, I will probably be using this code myself at some point, so not a bad idea to add it into utilities :)
Mikle
@mgarin

@/all

WebLaF v1.2.9, v1.3.0 and v2.x.x future

(TL;DR at the bottom)

I've got an important update about the future of WebLaF versions and releases schedule. As you might have noticed - project have been in a sort of a slumber in 2018 and start of 2019 and only had some important bugfixes and performance improvements added over that time. I have been working on changes in the background but haven't really delivered most of the changes made yet, but that is about to change.

So, first about the current styling branch - aka v1.2.9 update - I will now be focused on pushing the final release before the end of July. This is something that have been long overdue and have to be finished before moving on to new features and major changes. That is also why end of July is hard set deadline, it will not be moved, meaning you can expect the polished v1.2.9 release to be available on GitHub and Maven before the end of July.

Next thing that is going to be updated is WebLaF site. It might not be as exciting, but it has to be done to keep the library healthy and keep publicly available information about it in check. It have actually been finished long time ago, but I will have to add some up-to-date content to it as well as some new starter guides that will be available there. It will take some time, but will most probably be available somewhere between v1.2.9 and v1.3.0 updates.

Next step will be release of v1.3.0 update - it will include some missing styling features (like font management) and some new tools to increase styling system usability (like variables support). That update will give WebLaF users enough freedom to effectively use styling system for both minor and major style adjustments and ability to quickly create new styles. It will also include improvements for styling of any components that might have slipped through the cracks. Release of this update will most probably be somewhere between October and December this year. This will also be the final v1.x.x update including new features. Future v1.x.x updates will only add bugfixes and performance improvements.

Now regarding 2.x.x and later versions - those will only be supporting JDK8+ and later LTS JDK versions. So far I plan to base v2.x.x on JDK8 and v3.x.x on JDK11. Future versions (4.x.x, 5.x.x etc) will most probably be based on even later LTS JDK version (LTS = long term support). Initially I planned to keep JDK8+ support for all v2.x.x and later versions, but changes in Oracle release and support policy are forcing developers to use newer versions more often. Considering that, there is a good chance that pace at which new major WebLaF versions are released will increase. That also means that the supported JDK versions will change more often for the most recent releases.

The first v2.0.0 update will support JDK8+ and will, most probably, not be available earlier than 2020 summer. It will include important reworks for components based on older IO API, multiple code and API adjustments for JDK8+ and some other changes that are yet to be planned.

TL;DR

  • WebLaF v1.2.9 is coming at the end of July (<2 months away)
  • WebLaF site update that will feature some new library guides (~4-6 months away)
  • WebLaF v1.3.0 is coming at the end of 2019 (~7 months away)
  • WebLaF v2.0.0 is coming at the summer 2020 and will support JDK8+
  • Future WebLaF updates (v3.x.x and later) will most probably only support later LTS JDK versions
Laxminarsaiah Ragi
@Laxminarsaiah
Hi Team, this is Laxmi, I am learning java swings my self, after some research, I got to know about weblaf, I want to do some experiment like, drag a file from local machine to a remote machine(say VM) as WinSCP does. can anyone give me some example, please?
Mikle
@mgarin

@Laxminarsaiah
It is actually quite hard to understand how exactly you're seeing the DnD exactly -
Does your Swing application display remote folder and you want to be able to drop files on it to send them to that remote folder?

Either way, WebLaF won't be much of a help with DnD as it uses common Swing DnD APIs and nothing really else.
So I recommend reading this article: https://docs.oracle.com/javase/tutorial/uiswing/dnd/intro.html
This should give you all the basic information about implementing DnD in your application.

You can also check the FilesTransferHandler implementation:
https://github.com/mgarin/weblaf/blob/styling/modules/ui/src/com/alee/managers/drag/transfer/FilesTransferHandler.java
This abstract class provides a convenient base for files DnD implementation for any Swing component.
That being said, initiating the drag operation is still up to you, but drop will trigger whenever some files are dropped on top of the component using that transfer handler.
Mikle
@mgarin

@/all
Just a short update here - I'm preparing all of the changes that will be included into v1.2.9 update and also patch notes for that update right now, but due to the sheer amount of them this will probably take a while and actual release will happen tomorrow. But don't worry, update is ready and this is just a bunch of tedious pre-release work I have to do due to the long time since the last release (it's been around 5 years since 1.28 and around 4 years since 1.29 pre-release version).

Update will first be coming to Maven, then I will put it up on GitHub releases page and then will update current site with new downloads. New site will probably be coming somewhere in the next month or two.

I will post another update here once the release is live.

Mikle
@mgarin
@/all
Another update - unfortunately I've encountered some critical issues in the changes (last moment before pushing) and have been fixing them almost whole day which is forcing me to push the release for tomorrow to avoid any major bugs getting through. I'll be doing the last code check early tomorrow and releasing the update as soon as I'm sure there are no problems.
Mikle
@mgarin
@/all
Final v1.2.9 changes are now available in styling branch.
I'm now working on deploying release to Maven and will be updating GitHub project page and Site.
Luna
@l-Luna
and here I thought the project was dead :p
if I wanted to start contributing, where would I go first?
Luna
@l-Luna
also, is there a list of all of the weblaf components? most of them are in the demo, but (at least) the WebMultiSplitPane isn't
Mikle
@mgarin

@l-Luna
Project is certainly not dead, but it was in a slumber/slow transition to the new styling system for the last few years. Now I'm going to put some more time into it and push a bunch of smaller updates following v1.2.9 that will include more improvements and changes for existing components before I get to new stuff in v1.3.0 and eventually v2.0.

About contributing - honestly, it's hard to say. There is a lot of pretty complicated stuff you'll need to get into to make new components or adjust/rewrite existing component in WebLaF and it's gonna be really hard to explain the whole process and nuances online. Right now (and until v1.3.0 probably) it's mostly about revamping some of the remaining old components and adding new ones. And I do have some features planned for the later updates, but I'm not yet sure how those are going to be implemented in the first place. So it is hard for me to tell what code contributions you might actually be able to do.

Although there is another way to contribute to WebLaF project - report any issues that you might encounter with different components and features. That does help a lot. And I keep track of all issues until I fix them or at least find a decent solution.

Regarding the components list - I don't really have one, but there are quite a few. Also WebMultiSplitPane is surely available in the newer demo (v1.2.9) as well as a few other new features, but Sonatype is taking time with publishing the release so you might have to wait a bit to get your hands on it (should become available here soon: https://search.maven.org/search?q=g:com.weblookandfeel ).

Instead of the list - I am planning to release guides for all extended components on the GitHub project wiki over time. That way you will know which components are up-to-date and how they can be used. There are already some articles up, but not a lot of them as I was mostly focusing on finishing the code work first.

Hanns Holger Rutz
@Sciss
:thumbsup:
Luna
@l-Luna
I've been messing about with the Skin Editor, but I can't find how to change the background colour of the breadcrumb. Setting the background of the panel's component doesn't do anything (unless I remove the painter, which breaks the UI) and I can't find any way to do so through the painter.
Luna
@l-Luna
or, is there a way to change any of the StyleConstants through skins?
Mikle
@mgarin

@l-Luna
I recently answered on a question of how styling works in the new version, probably it can be helpful:
https://github.com/mgarin/weblaf/issues/514#issuecomment-516793911

Basically all styles for all components are now stored separately from the code in XML files. You need to make a skin or an extension, attach it to the L&F and then you can modify any styles in it. You can also find all existing styles in the default skins directories, for instance here is breadcrumb style files:
https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/skin/web/resources/breadcrumb.xml
https://github.com/mgarin/weblaf/blob/master/modules/ui/src/com/alee/skin/dark/resources/breadcrumb.xml

And generally this is the light skin:
https://github.com/mgarin/weblaf/tree/master/modules/ui/src/com/alee/skin/web
And this is the dark skin:
https://github.com/mgarin/weblaf/tree/master/modules/ui/src/com/alee/skin/dark

Mikle
@mgarin
Regarding specifically the breadcrumb background - you normally don't see the flat backround it has, but instead looking at the background of it's child elements since they take all the free space. So to change the visible background - you need to adjust styles of the child elements of the breadcrumb. The bad news are - there are a lot of child element styles in breadcrumb that you will need to adjust to change all possible variation colors. Although you can simply adjust the ones you need - for instance if you're using buttons in it - you only need to adjust this one:
        <!-- Button -->
        <style type="button" id="button">
            <painter class="BreadcrumbButtonPainter">
                <decorations>
                    <decoration states="first">
                        <BreadcrumbElementShape sides="right" corners="right" cornerWidth="6" round="1" />
                        <WebShadow type="outer" width="3" />
                        <ButtonLayout padding="0,0,0,8" />
                    </decoration>
                    <decoration states="middle">
                        <BreadcrumbElementShape sides="right" corners="left,right" cornerWidth="6" round="1" />
                        <WebShadow type="outer" width="3" />
                        <ButtonLayout padding="0,8,0,8" />
                    </decoration>
                    <decoration states="last">
                        <BreadcrumbElementShape sides="none" corners="left" cornerWidth="6" round="1" />
                        <WebShadow type="outer" width="3" />
                        <ButtonLayout padding="0,8,0,0" />
                    </decoration>
                    <decoration states="single">
                        <BreadcrumbElementShape sides="none" corners="none" cornerWidth="6" round="1" />
                        <ButtonLayout padding="0,0,0,0" />
                    </decoration>
                    <decoration states="progress">
                        <BreadcrumbProgressBackground id="progress">
                            <GradientBackground>
                                <color>109,206,91</color>
                                <color>77,201,87</color>
                            </GradientBackground>
                            <MovingHighlightBackground id="overlay" orientation="horizontal" width="120" color="255,255,255,210" passes="1" duration="1s" delay="4s" />
                        </BreadcrumbProgressBackground>
                    </decoration>
                    <decoration states="indeterminate">
                        <GradientBackground>
                            <color>180,200,255</color>
                            <color>170,190,245</color>
                        </GradientBackground>
                        <MovingHighlightBackground id="overlay" orientation="horizontal" width="120" color="255,255,255,210" passes="2" duration="1.5s" delay="0s" />
                    </decoration>
                </decorations>
            </painter>
        </style>
Luna
@l-Luna
oh, oke. thanks for the help.
Mikle
@mgarin

@/all Release notes for v1.2.9 are now available on GitHub:
https://github.com/mgarin/weblaf/releases/tag/v1.2.9

Release is also available on Maven Central since Friday:
https://search.maven.org/search?q=g:com.weblookandfeel

I will add a few new component wiki guides this week and update a few outdated ones.

I will also be sorting out all open issues in GitHub tracker for the next few smaller updates.
Next v1.2.10 update will most probably be out closer to the end of this month and will include more component & styling improvement along with some fixes.

Mikle
@mgarin

Regarding the next updates - I've updated project page & milestones on GitHub:
https://github.com/mgarin/weblaf/projects
https://github.com/mgarin/weblaf/milestones

I'm planning to spend 2~3 weeks per update until v1.3.0 which will certainly take some more time.
Although v1.3.0 will mostly be a feature update because I plan to add all necesary changes/fixes/improvements for the components styling before that.
So expect a steady stream of updates for WebLaF and if you have any issues with the new releases - don't hesitate to report them.

Mikle
@mgarin
New demo application is now also available (with all dependencies included in JAR) on release page:
https://github.com/mgarin/weblaf/releases/download/v1.2.9/weblaf-demo-1.2.9-jar-with-dependencies.jar
Mikle
@mgarin
I have updated How to use WebLaF wiki article with some additional information on the current WebLaF modules. I will be keeping it up to date with the future module changes as well, so you can check that article if you are unsure which WebLaF modules you need.
@l-Luna
By the way, you were asking about a full list of WebLaF components - you can check v1.2.9 release notes - I have added a full list of updated/supported components there with their current state. There are still a few other components available in the library that are not mentioned on the list, but those are most probably quite dated and aren't yet recommended for use - I will eventually get to update them all and will probably post that list with the current states separately on wiki.
Mikle
@mgarin
I have also updated short How to build WebLaF binaries wiki article since all ANT builds have now been removed and there are only Maven pom.xml files available.
manny kung
@mokun
Mikle, do I always need to get an instance of the class CustomSkin when declaring the use of an xml skin ?
Mikle
@mgarin

@mokun
Not really sure what you mean by that.
Also CustomSkin class have been removed and isn't in the latest version, I guess that you were coming from the introduction guide - I'll need to update it a bit.
To make a custom skin you need to use or extend XmlSkin and provide the XML resource to it in constructor.
Then you need the skin's XML file itself with settings, description, styles etc.

At that point you can just use the instance of XmlSkin or your class that extends it in the StyleManager.
If you make your own class that extends XmlSkin you can also simply provide it into install method of WebLookAndFeel and it will create instance on its own.

Mikle
@mgarin
@mokun @/all
I have updated "Styling introduction" wiki article according to changes in v1.2.9 update, you can read it here:
https://github.com/mgarin/weblaf/wiki/Styling-introduction