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 thestyling 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 alreadythere:
- 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.
- 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.
- 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.
- 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 instyling branch and can be put to test, but I will come back to this topic a bit later on this post.
More
