web analytics

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.


Branch “styling”


I have added a temporary project branch styling on GitHub WebLaF project page – almost all new changes are added there right now. This branch contains changes required to enable styling support for all existing components. It isn’t stable right now and might even be uncompilable sometimes, but as soon as I finish adding modifications it will be merged into the master branch and I will finally be able to release v1.29 update.

I was going to postpone a lot of those changes and release only small chunks one by one but that would force me to add even more workarounds for older parts of the code. So I have finally decided to finish it in one sweep. Originally this was the goal of v1.40 release, but it is coming sooner than expected. Some improvements will still be made on the way to v1.40 release, but the main part will be added in v1.29 update and it won’t be a simple preview – it will be fully working styling system.

So let me go into some specifics of changed you can expect…


Swing tips – issue #2


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!..




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

Swing tips – issue #1


With a small delay, but as promised – I am starting a new series of posts about various Java and Swing tips & tricks that might help you understand it and develop awesome-looking Swing applications of any type.

Check out the first three tips under the cut.


News and v1.28 release


About news and site updates

As you might have noticed – it was a really long time since last post here, I were still releasing new library versions in background but I didn’t post here due to time constraints and since I didn’t actually find anything specific worth noticing. I have taken all that time to think about structuring information on the site better and improving the library itself. So today’s post will bring a few important news and v1.28 release notes.

If you were tracking GitHub updates you might have already seen some of this post parts in the README file on the home WebLaF page on GitHub, but this post contains some extended comments and notes, so make sure you don’t miss anything!

Let’s now continue to the interesting part…


Changes reason


…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 :)

Changes in this year…


Recent news

A lot of time passed since the last post here, so i will tell about all of them right now.

But before that i want to say thanks to everyone who helped me to improve WebLaF project and push it toward the right direction!  Was it a small feedback on some specific component, feature requests or bug reports, some interesting new ideas, translations or something else – i really appreciate all the help i got from you guys. Thanks again!

And i am looking forward to get even more feedback on this project as soon as it moves to the next stable stage and will get more awesome stuff included! 😉

Anyway, let’s leave the lyrics and move on…

GitHub and project changes

I spent a lot of time to improve project this year and i have tried a lot of tools.
There will be more changes coming but i am really satisfied with the work done.

Thanks to GitHub everyone can implement some custom feature into WebLaF sources and make a pull requests so i can quickly view it and merge into the main WebLaF branch. You can read more about making pull requests in GitHub help here. So don’t hesitate to make a pull request if you really want some feature included directly in WebLaF in a short time!

GitHub also offers a good way to handle various issue requests, so i would really appreciate if you post them here – https://github.com/mgarin/weblaf/issues. WebLaF forum will be more like Q&A section, but you can still use it if you like that way of communication more.

By the way GoogleCode project is now deprecated so i recommend you to get newer project/sources version from GitHub if you were still using the one from GoogleCode SVN.

Shortly about other changes with the project:
1. I have improved ANT build and added some more build options
2. Artifacts names were changed to make them brief and understandable
3. A lot of changes done to classes structure, code style and used libraries

Now let’s move on to major changes made this year…
(you will find more information under the cut)


Last steps to v.1.4 release


A few things concerning the site and such

I rarely post updates here because it takes a lot of time to prepare any really useful information.
Its much better to spend that time on the library development instead :)

But be sure – project is alive and will be alive (unless Oracle decides to deprecate Swing but i hardly believe that will happen).

But everyone wants to hear something once in a while – that is why i added Roadmap which gets updated with almost each commit.
You can also see all the changes in the commit comments on Google Code project page – its the same as the list posted as “done” in roadmap.

Also as i said many times – feel free to contact me at anytime if you have any questions or suggestions.

About the release

Already 6 months passed since 1.3 release and i have finished most of refactorings and library overall performance improvements – now it works much smoother and the code is finally clean enough to use it without any limitations. There is still a lot to be done (well, as always) but i will move most of unimportant features into next releases and will finish with main things that have to be done to achieve a stable version.

So, here is what i want to finish until v.1.4 release:

  • Quick, clean and functional filechooser UI implementation
  • Proper colorchooser UI implementation
  • Dockable pane and Dockable frame components
  • Critical bugfixes and small useful improvements

I won’t say that these features will be added soon, but i hope to finish most part of it until the next year – so it is about 1.5-2 months.

You can still keep an eye on the changes i add into the preview library build  (or just track the SVN changes) and use it instead the old version.  The old v.1.3 version is actually deprecated and will be replaced by the new upcoming preview build, which is already much more stable and useful than the older versions.

Roadmap & build


Project roadmap

Since new versions takes pretty much time to finish and assemble i have decided to populate upcoming versions roadmap and keep it updated. This roadmap is much more specific than just some abstract “future plan” and it contains all of the features/bugs/improvements i am going to finish before the final version release. Roadmap might also be modified several times to include or exclude some of the changes depending on the situation. All changes marked with GREEN might be found in project sources even before the final release.

ANT build script

To make source code comfortable to use i have added ANT build script into the project which has 6 targets:

  • Build WebLookAndFeel.jar
  • Build Sources.zip
  • Build WebLookAndFeel_demo.jar
  • Build NinePatchEditor.jar
  • Run WebLookAndFeel_demo.jar
  • Run NinePatchEditor.jar

Using them you can build exactly the same libraries/packages i am uploading to this site when new version is released.

You can read an extended “how to build” description in FAQ forum topic here: