@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.
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
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 );
}
} );
}
}
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 #52styling branch mgarin/weblaf@ec2e395New snapshot build with it should also be available in 15-20 minutes
@/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
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.
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.
@/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.
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.
@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.
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.
@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
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>@/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.
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.
https://github.com/mgarin/weblaf/releases/download/v1.2.9/weblaf-demo-1.2.9-jar-with-dependencies.jar
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.
pom.xml files available.
@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.
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
Merge and Clone trying to modify Field.modifiers through reflection, which is no longer allowed. (Related: https://stackoverflow.com/questions/56039341/get-declared-fields-of-java-lang-reflect-fields-in-jdk12)
@l-Luna
Unfortunately current versions only supports JDKs 6-8. They should also be working under JDK 9-11 properly, but not thoroughly tested on those and you will also receive warnings about Reflection calls in the logs.
There are quite a few issues with supporting JDK 12+ in WebLaF right now as it uses Reflection to access fields & methods to configure components and setup styles on top of adjusting field modifiers sometimes. Rewriting all related code is not an easy task if possible in the current version at all, considering that a lot of Swing code is simply package local or private and have to be completely rewritten to get rid of Reflection usage.
That being said, we are going to switch to newer JDK versions for our internal projects in near future, so this will have to be solved at some point, but I have no real ETA for the JDK 12+ support.
I've added an issue #525 you can follow to receive updates on the case.
Rework and some fixes for desktop pane and all related components is coming next week along with some major refactoring across the project.
And tabbed pane revamp will be the last big change for v1.2.10 update.
A small update here ~
I'm finishing last changes for v1.2.10 update and I wanted to post bit of info on it.
You can look at all upcoming changes here: https://github.com/mgarin/weblaf/projects/9
The main thing is of course JTabbedPane complete styling support - yes, it is FINALLY coming. I managed to solve all of the problems (or at least it seems so) that I've been facing with inadequate Swing implementation of JTabbedPane model and incomplete property change events.
There is a catch though - I've completely changed the way JTabbedPane works from the inside. Basic JTabbedPane UI implementation mixes a few different layouts, painting and tab components rendering all together in one big mess. I've got rid of it early on because it is simply impossible to use with WebLaF's styling system and started to code my own take on it.
This should not affect your experience as a L&F user, but it might affect your code if you have been relying on some UI implementation specifics. Although this is most probably a very rare case.
So here are some key differences between WebLaF JTabbedPane implementation and Swing/other L&F implementations:
WebLaF implementation uses multiple layers of components - tab area itself, tab viewport, additional controls and even tab themselves - all are implemented using standalone Swing components. That allows deep customization of each visual element of
JTabbedPanethrough styling system as well as easier customization and expandability of the UI itself.WebLaF implementation uses different approach for
JTabbedPane.WRAP_TAB_LAYOUTmode - all tabs are wrapped from left to right and top to bottom forTOPandBOTTOMtab placement, top to bottom and left to right forLEFTandRIGHTtab placement (and there are also some differences for RTL orientation). It also does NOT bring selected tab closer to the content area, basically keeping all tabs on their original spots at all times unlessJTabbedPaneitself is resized. BasicJTabbedPaneUI implementation does wrapping differently and also brings selected tab closer to the area.WebLaF implementation allows customization of tabs stretching mode through the style. There are generally 3 modes described by
TabStretchTypeenumeration:never,multilineandalways. All three modes are available for both of tab layouts - wrap and scroll. Stretching mode simply defines whtether or not tabs are being stretched within the tab run to fill-in the remaining space. Default mode ismultilinewhich functions the same way basicJTabbedPaneimplementation does.Tab focusing feature have been removed completely meaning you cannot switch focus between tabs without changing tab selection anymore, tab selection is now basically the same as tab focus. This feature, as far as I'm aware, was only used in native GTK look and feel and I'm not sure whether anyone ever actually used it as it is pretty much useless.
Hotkeys for tabs have been simplified, partially due to the focus feature removal and partially because of some other code changes. Two new hotkeys have been added - Alt+Left & Alt+Right for
WHEN_ANCESTOR_OF_FOCUSED_COMPONENTcondition - to allow quick and convenient navigation through the tabs when focus is within tab content. Hotkeys, just like with any other L&F, can be replaced or removed by modifying component'sInputMapdirectly or it's settings within UI defaults.
Overall these changes should make usability of JTabbedPane a bit better while also providing better tools for it's UI customization. There is a chance that new implementation might still have some unresolved issues (like #527 with WebCollapsiblePane rework), but I'll be ready to hotfix those asap.
JTabbedPane as I wanted it to be something simple, but it can be heavily customized just through the style alone.
You can check all changes included in v1.2.10 update here: https://github.com/mgarin/weblaf/milestone/21?closed=1
Although that is most probably not a complete list and I will keep it updated as I continue working on it.