Update on “styling” branch changes

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.

What is yet to be done?

Shortly – new demo application, some component and painter improvements, a few UI-related tools, dockable pane component and a minor bug fix for various small issues. The reason why those changes specifically are not yet done is that almost all of them require stable and polished underlying styling system. This is exactly what I spent a lot of time on so from now on I am starting to roll out smaller chunks of updates for specific components and features.

Here is the full list of unfinished things:

  1. Brand new DemoApplication
    • Application base is somewhat finished but will still be improved before the final release
    • Examples are currently being added into the existing demo application
    • Some features and options of this application are still to be done
  2. Component and painter improvements
    • Chaos that was left after painting code was moved from components/UIs has to be sorted
    • Some painters still need major improvements and those changes must be included now
    • Various previously unconfigurable settings can and should now be made configurable
  3. StyleEditor component
    • Improvements to the UI and functionality required to allow full control over styling
    • Some major improvements required to run this tool over existing application
    • Some minor improvements required to run this tool in a standalone mode
    • Some minor improvements required to allow integrating this tool into your own application
  4. WebDockablePane component [ #37 ]
    • Implementation of this component is partially done and will be available before the release
    • Various parts of this component need enhancements according to latest styling changes
  5. Set of issues planned for this release [ list ]
    • Multiple old styling issue fixes
    • Other minor issue fixes and enhancements

It might look like a lot, but it actually isn’t that much, not even close to the amount of work that have already been done to bring this major WebLaF improvement live for sure. But it will certainly take some time to be coded, tested and polished before the final release which will hopefully make WebLaF users enjoy developing their application UI. This leads us to the next topic…

ETA on v1.29

Yes, I have already published a few possible release dates before and I was trying to meet those, but it didn’t happen because of multiple reasons – the amount of changes I wasn’t expecting to be required, new included features and enhancements, projects I had to work on apart from WebLaF and some other minor things.

Now when I can clearly see the scope of the features, improvements and fixes and I am aware of my schedule for the next few months – I can actually tell the ETA on this update: 25 January 2016

I will be pushing the release earlier if it will be ready which might be the case. I was initially planning to have it at the end of the December, but I don’t really think that changes to be done will fit into one month from now, so I have to push the final date ahead to make sure it will be delivered and it will be in a good shape – I don’t want to release half-baked product.

Also from now and until the release day I will frequently commit small chunks of changes into the styling branch which will fix existing issues, add enhancements, new features and provide additional demo examples. I will also be making changes according to the feedback on the pre-release styling version.

So… back to waiting?

No, not this time! I am aware of how frustrating could it be waiting for new version and any news at all for so long, so starting from now things are going to change.

First of all – I have built and published separate styling artifacts based on current styling branch. You can find them in download section and below:

Note that those artifacts are built from the latest “styling” branch source code available on GitHub right now using provided ANT build script. You can build them locally if you want to try out some newer changes later on before the final release.

This build has a lot of visual issues so far, I even might not be aware of some of them, but the general API for skins, components, UIs and painters is almost finished, so you can try it out and see if something is missing or contains issues. I really need to hear your feedback on it!

Secondly – I have prepared a big introduction article on GitHub wiki for the styling system – Styling introduction – I strongly recommend you to read it first before trying out new pre-release artifacts. There will also be more articles covering features coming with this update later.

Important note

I would strongly recommend not to include that version into your live projects yet because it is:

  • Incomplete – I have polished the styling part, but major API breaks might still occur for other features
  • Has a lot of issues – it is certainly far from being stable as some components might not even run properly

This release is only a preview build for those who want to try out new features ahead of time and maybe give some feedback to me so that I can improve the quality of the final release.

So if you have some questions after reading introduction article, suggestions or questions about the styling system itself or something else – contact me anytime. I’ll do my best to answer your questions in the shortest possible time.

Any specific plans for the future?

There are a lot of plans. I’m not going to stop supporting and improving WebLaF and I will push a lot of exciting improvements and features in the next updates to get some fresh air into Swing UI development.

Here is a general list of things I am planning to do after releasing this update:

  1. Styling system enhancements
    I really need your feedback on this! Of course I already tried this new system on a few internal projects and it is far better than the previous one, but I am pretty sure that there might still be some hidden issues to fix and/or obvious enhancements to make. So what you might do at this point – try implementing some of the custom styling you have and see if something is not working as you think it should or it is simply broken. I already have a few enhancements planned for the next update which are mostly QOL for XML format.
  2. Additional ready-to-use skins: #54 #58 #108 #169 and others
    I promised this long ago and I wasn’t lying. Thanks to the new styling system UI customization is times easier and much more convenient now, so I will be releasing various skins available on top of base WebLaF one. You can already find some of my first tries on the dark skin in the new demo application – by the way this one will be released with v1.29 as well – but this is just a beginning. I am sure some of you will come up with some pretty amazing custom skins as well 🙂
  3. WebLaF modules and versioning improvements: #336 
    This change is intended to separate some complicated and tangled WebLaF code into smaller separated modules and also remove some unwanted dependencies between currently available modules. Current three modules have proven to be really useful so I am going to break them down even further. Don’t worry – single JAR builds will still be available for convenience and aren’t going anywhere. This is intended more to assist me in splitting WebLaF code properly across modules and keeping it clean. Also it might be useful for some of you to exclude unwanted WebLaF features from your projects.
  4. Easy-to-use SVG icons: #337 
    SVG became a pretty popular image format and it is actually convenient and optimal way to store your application icons. I want to bring power of SVG into Swing applications – I will provide some features based on it within one of WebLaF modules. It will allow you to use SVG icons within common Swing components and extended WebLaF components where they are applicable. You can actually already see some SVG icons being used across new demo application UI.
  5. More extended components: #32 #138 #141 and other popular ones
    There was a “component drought” for quite a while in WebLaF as I had to restrain from adding any new components until I finish with WebLaF core features to avoid adding more chaos into the code. Starting with next update I will be introducing several popular and some new components into the library.
  6. Enhancements for existing components
    Even though I am planning to add new components I don’t want old ones to be left behind. I will be adding more features and enhancements to currently existing components – some of those will be “patched up” in v1.29 release already, others will surely be updated in next versions.
  7. Cleaning up some of the mess left in the code
    I got rid of the most of it already, but there are still some “dark corners” of the library I haven’t touched yet. I will be addressing those between the releases and will fix a few old annoying issues along the way as well.
  8. Improvements to JavaDoc and code
    I consider JavaDoc to be one of very important parts of the code as it not just helps everyone to use the library properly, but it also helps me to navigate the code and apply changes. So I want to ensure that all important parts of the library are properly documented and, what is also important, understandable. Therefore I do my best to keep the code clean, documented and readable.
  9. Enhancements for 9-patch editor and related features
    Several enhancements for this editor were planned for a long time already and I will be adding those. There will be improvements to editor itself, possibility to work with multiple images at the same time, have multiple previews on the right side and some other enhancements.

Some of these things will already be available in v1.3.0 update while some are planned for later updates.

And in a longer term – I will be starting a Java FX -related project that will provide features similar to WebLaF but for Java FX applications. I am not yet sure about specifics of that project so I can’t say much right now, but since UI future for Java seems to be slowly shifting to the FX project it is certainly something I will be doing. Though once again – this is not even close to being developed and probably won’t be for at least a year, so that will not affect current WebLaF development anyhow right now.