WebLaF - Java Look and Feel

Not to waste any time I’ll start with important part – WebLaF v1.2.9 release is now available on GitHub. It’s been in development for quite a few years in which library API undergone some major changes and improvements. Most of the components have been updated or completely revamped. A lot of “bridge” methods that have been haunting me in older versions have been removed in favor of the new unified styling system. A few new big components like WebDockablePane and WebMultiSplitPane have been added to the library. A lot of managers and utilities undergone some changes and improvements. Countless bugs and memory leaks have been squished. You can check condensed patch notes on GitHub release page.

Now you probably still have a few questions:

• Why is it just v1.2.9 while changes are worth a whole 2.0?
• What is going to happen in the future updates?
• Why are some components still have older style structure?
• Where is the promised new site and guides?

I’ll try to answer those questions and more in this post.

More

I’ve got quite a few questions over last few months about what “derivative works” means in WebLaF commercial license agreement – it is true that this statement is unclear and might be interpreted differently. Under that statement I always meant any look and feel library written based on WebLaF and it hasn’t changed.

To avoid further misunderstandings and make the agreement transparent I have added a few changes which you can find under the cut.

This post purpose is to ensure that everyone are aware of these changes and of the fact that nothing will actually change for commercial WebLaF users. These changes will not cancel or affect any freedoms granted by the agreement anyhow and are only focused on making agreement more convenient.

More

Release date is getting close now and while working on the update I have realized that even I have to peak into my own JavaDoc and code from time to time to make sure that things are working the way I want and expect them to. Of course I tried to make a lot of convenience improvements with this update everywhere I could, but its scope is still huge and I possibly missed a few spots here and there and I can’t really replace all the legacy in just one update even though it took quite a while.

So before the release hits and you will have a lot of questions to ask about various changes and new things introduced in WebLaF v1.29, I was looking for one more way to communicate to ensure that you can get help in shortest possible time. So far it was mostly GitHub issue tracker, some emails and a few forum posts once in a while.

• GitHub issue tracker is really good, but it might get crippled by lots of question issues or long discussions which sometimes are probably not even related to topic.
• E-mail communication takes time and it is not efficient when you want to quickly discuss some matter and get some code tips, especially when it is critical for your development process.
• Forum have proven to be inconvenient and I am planning to shut it down and also bring some major improvements to the WebLaF site next month.

Just a few days ago I stumbled upon Gitter service and shortly after looking into a few example usages I decided to try it out. Gitter is an online chat with a pretty awesome GitHub integration and support for lots of QoL features you will miss trying to communicate through email or forums. It has one general public room and possibility to have private user-to-user conversations.

Feel free to stop by and chat with me about WebLaF!
 https://gitter.im/mgarin/weblaf

There are also Gitter apps for different OS/devices:
https://gitter.im/apps

Before wrapping up I want to mention that I will start pushing some major changes into `styling` branch this week. One of the big improvements will be the big change to the basic decoration painter that will now be able to hold settings for multiple states instead of just having one plain set of visual settings. Along with that change I will also be updating all themes for the components using that painter.

Since all changes related to the styling release (and even this post!) took much longer than I could have expected in any scenario – I decided to make another update about the styling branch and v1.29 update. This post should give you general idea of the changes scope, current state, some highlights on new features, probably interesting things to discuss and… an ETA on the final release date! Yep, I can now actually say with a high level of confidence how long will it take me to finish this release. But first things first.

What have been done so far?

The amount of work put into this single update is actually getting close to the initial amount of efforts put into creating this library in the first place or probably already exceeded it, no kidding. This is one of the reasons why I have delayed the release date multiple times and still working on it. I could have postponed these changes until v1.3.0 as it would seem to be reasonable version and changes -wise, but I really didn’t want to delay it any longer as multiple features everyone wanted required it.

A lot of concepts I initially planned to bring to life – like non-specific painters for components, painter settings bridge methods, plain direct styling of components and a lot of other smaller things – proved to be ineffective and/or inconvenient usage and development -wise. Because of that I had to start some things over from a scratch. Just StyleManager itself went through more than five iterations, but that was inevitable as I had to try out each possibility and see whether or not it is convenient enough to be used within real applications and not just for demonstration. It also important that this system should fit into some of Swing concepts without causing a lot of issues – that certainly limits possible solutions.

Current version of styling system – which can be found in project styling branch on GitHub – is almost ready and should be able to handle lots of use cases. It also provides a lot more style settings, features to use and some tools to run over your application to debug UI to find various issues and bottlenecks.

One last thing before you can jump to the feature lists – a few important definitions I will use to describe the changes:

• Skin – A set of styles defining how your UI will look like
• Style – A set of rules and sub-styles defining how single UI component look like
• Painter – A single class implementing com.alee.painter.Painter interface and containing actual component painting code

Now let’s start with a list of features which are already there:

1. StyleManager features
   • Skins management – possibility to install global skin and component skins
     This allows you to setup a single global skin which is used by all new components and then modify skin for each specific component or a group of components which will force them to stick to that different skin until you reset it to default global one.
     
   • Styles management – possibility to reassign component styles globally and on per-instance basis
     This allows you to provide and modify style used by each specific type of component (for example JButton) globally and provide a distinct style for specific component instances across your application UI. This covers a lot of possible style use cases – either you are using specific skin “as is” for all components within your application UI or you want to customize separate some or all of them to look differently using either predefined optional styles or your own ones.
   • Painters management – possibility to provide custom component painters on per-instance basis
     This might look strange why I would put this small side feature in the list here, but it isn’t actually that small. The idea behind this styling update is that you will simply use a predefined skin and also apply specific style IDs to your components where you need them to alter the UI and you don’t really need to write styling-related code (apart from specifying StyleIds if you need them). But in case you actually want to have some interaction between how your UI works and some code in your application – you will need a direct access to the painter the component is using. This is where you might actually want to provide a custom painter for your component.
2. Skin XML format features
   • Possibility to provide complete skin description within single or multiple XML files
     Under skin description I mean its styles and their settings plus some general information – skin author, its description and skin class. Since every skin will contain a huge amount of styles and could easily become very complicated I have added includes support – you can generally include one skin into another one. Specifics on how exactly that works can be found in wiki articles referenced later in this post.
   • Possibility to reuse, extend and override styles
     Since every component from now on will contain a lot more settings to be provided through styles – it could very hard to create new ones since you will have to specify all the settings in each new style to avoid issues within painters and UIs which now won’t have any default values. To avoid that issue all styles you define in XML will automatically override existing style with the same ID or extend the default style of the same type. All settings from overridden or extended style will be carried to overriding or extending style in which you can simply specify the ones you actually want to change.
   • Possibility to override default component styles using default style IDs
     It is generally a result of the feature described above but I wanted to have a separate note on this one. To create your own unique style for some component – for example a button – you don’t need to specify all of its settings, you can reuse default settings (by including some of the default skins) and simply add settings you want to modify in your skin – other settings will be taken from the default button style defined in the included skin.
   • Possibility to provide all settings for painters, UIs and components within styles
     Every single style can contain component, UI and painter specific settings. Those settings are simply defined by the fields that component, UI or painter implementations have. That means you don’t need to guess which settings you can provide or what specific setting does – it can always be easily found in the corresponding class JavaDoc. Or you can simply test any specific setting through StyleEditor on a live component.
   • Possibility to create any amount of custom styles with unique IDs
     You will most probably need to create your custom component styles for some specific cases – a unique status bar button, emphasized message panel, custom notification etc. – for all those cases you can create custom styles with unique IDs within your skin which then you can apply to the components using StyleId built on the style ID you have specified in skin.
   • Possibility to create style structures
     This is the last, but also the most complicated feature I’ve spent a lot of time and effort implementing. It allows you to enclose styles within each other creating some sort of styles tree which then can be applied to actual Swing components tree. That feature allows creation of consistent styles for complex components like JScrollPane, JComboBox, JFileChooser and others which contain multiple JComponent implementations within itself.
3. Components structure rehaul
   • Style-related settings
     All style-related settings were moved from Web-named components and their UIs into their painters. Bridge methods which were previously available are not there anymore and if some are still available – those will be removed before the final release. This was a good feature for some cases but it also forced you to create a lot of styling-related code around your components which is certainly not helping and in many cases even hurting overall code readability. And generally that stuff shouldn’t be there in the first place. From now on you can specify all style settings within the skin, but if you need to directly access some settings from the code you can still use custom painters.
   • StyleId parameter
     It is now possible to attach each Swing component to its specific style in skin using StyleId which basically contains component style ID as String and can be referencing parent styleable component. There are also new constructors added into all Web-named components with StyleId being a first parameter.
   • New interfaces for bridge methods
     There are also a lot of new interface-based bridge methods provided for various groups of components – like Styleable, Skinnable, Paintable, MarginSupport, PaddingSupport and others – to simplify WebLaF managers and some component features usage. Those methods are different from previously provided ones as they are usually available in multiple components and are also used for various checks.
4. Painters rehaul
   • Specific painters
     Originally painters were simply a background/borders replacement but now they can handle painting a component fully. Each supported styleable component now has its own painter interface – like ButtonPainter or TabbedPanePainter – which might contain some specific methods required to be implemented. I call such painters “specific” as they are actually specific for each existing component and its UI class.
   • Custom painters
     Even though there are component-specific painters base Painter interface is still unrelated to any kind of components and its implementations can be used as background painters and will actually be used in some component-specific painters to provide custom decorations or background.
   • Painter features
     Since painters are now fully involved in the styling process across all components I had to expand the set of features available there to support various use cases. Painters now have direct access to component and its UI at any time to provide you with a full access to all their settings. Painters now also support various listeners which are used to update component view directly from the painter.

To sum up – all core features related to StyleManager are already done and should be working as intended with some minor issues which I am addressing right now. These features are already available in styling branch and can be put to test, but I will come back to this topic a bit later on this post.

More

There was a big delay since the first issue, but I am back now and have gathered a few more useful tips and examples. Hope you will find them useful!

List of tips:

• Java FX browser in Swing application
• JDK8 lambdas and Swing
• Using hotkeys
• Component isValid method

Check them out under the cut!..

More

For those who might be interested in PluginManager feature from WebLaF core – its tutorial is now available in WebLaF Wiki on GitHub.

PluginManager is a large feature that was added into WebLaF library core with v1.28 update. It provides a simple and convenient way to load, store and use plugins within your application. It also handles lots of possible load problems and provides tools to filter out unwanted plugins and a lot more…

There are also some other tutorials there which you may find useful.
Follow this link to see the full list: https://github.com/mgarin/weblaf/wiki

…or “why you like some specific components that much?”

Some of you might have noticed that some specific components/classes (for example WebTree) and usually everything that is connected to it are getting much more improvements and fixes than other components. Some components sometimes might not get any updates at all. So i want to give a brief explanation to that.

Basically, like any other developer i want to have ideal code in WebLaF and i want to do a lot of refactoring all the time. But library will not advance and become better if i will stuck in just refactoring. So i simply do some massive refactoring, JavaDoc additions and improvements to specific group of components from time to time. That allows me to cleanup that group’s code, add all required features and make all necessary improvements at once so i won’t need to change that code ten times. In advance that makes things faster and allows me to deploy more fixes and improvements.

And these are the reasons (sorted by priority) why i would choose some specific group:

1. It is used by some important components or by a lot of components
2. It code is outdated and has a lot of bugs and/or causing a lot of problems
3. It is tightly linked with another group of components that was recently refactored/updated
4. Simply because it is not yet refactored/updated

There might also be some other reasons to refactor/update some code.
For example someone requested specific changes or i simply bumped into some really ugly/non-optimized code.

Anyway, i am always open for suggestions (including the ideas about specific code parts), feel free to post/ask anything 🙂