Tips About Compatibility Issues With My Latest Commits

I just committed some major refactoring to the LWUIT code base the other day, I changed the way Dialogs work so the style of the Dialog UIID actually surrounds the "dialog" as one would expect... This works really well but is highly incompatible since the change required quite a bit of hacks. I also moved the alignment attribute into the Style class which doesn't seem like something that would break compatibility but it does.

If you are running into problems with your existing code try the following:

You can use the old Dialog logic by invoking Dialog.setDialogTitleCompatibilityMode(true);
This is mostly intended as an intermediate solution until you can fix your theme/code.
If you used Dialog style manipulations by changing the Dialog's content pane this will no longer work as expected! You will need to use the Dialog.setDialogStyle/UIID() methods instead.

If you find that alignment is broken for some use cases its usually triggered by changing the style after setting alignment. The solutions for this are to either define the alignment in the theme or just move the alignment setting code to a point after you change the style e.g.:
cmp.setAlignment(LEFT);
cmp.setUIID("SomethingElse");

Will replace the style component in the component and break its alignment, you need to make sure this doesn't happen.

Breaking To Make Things Better

The side image to the post has nothing to do with the post, just a screenshot of the new MajiPic application from majimob.

Our stance on API backwards compatibility has always been to try as hard as possible but no more than that. When we find design mistakes, even painful ones we choose to cut them down and fix them even with a compatibility issue especially when the potential benefits are noticeable.

We are now in the process of fixing a mistake in Styles in regards to the fgSelection/bgSelection properties. We intend to make two potential styles for every component: Selected and unselected.

Let start with the practical terms... We would have three methods to get/set style in LWUIT's components: getStyle(), getSelectedStyle() & getUnselectedStyle().

The getStyle() method will return the selected/unselected style based on the focus state of the component so you will no longer have to write:

if(hasFocus()) {
color = getStyle().getFgSelectionColor();
} else {
color = getStyle().getFgColor();
}

Instead this will work pretty much as you would expect:
color = getStyle().getFgColor();

This would also mean that get/set*SelectionColor would now be deprecated. But this goes deeper still, we have some various hacks such as focus/pressed borders which will now be deprecated as well.

This is pretty revolutionary and we intend to offer a migration path to ease the pain, the Style class would have a compatibility mode flag which will implicitly synchronize the selected/unselected styles. Furthermore, calling the selected color methods will try to "do the right thing" for most use cases.

However, we are doing this for a reason and this compatibility will break if you try to leverage the newer features enabled by this change such as the newer LWUIT Designer (resource editor). This would allow designers to define far more elaborate themes with the LWUIT Designer including complex backgrounds depending on component state (we intend to offer "meta-styles" as well but this isn't finalized). If you will use the newer version of the LWUIT Designer you will be forced to disable compatibility mode which will naturally break these features. We feel that this new approach is far more intuitive and powerful!

Following is a short mini faq for this change with questions Chen and myself raised about this feature:

Q: Won't it increase the overhead to add a selected style for every component?

A: Selected styles are created lazily and so won't exist for most components, they will only be created when the component actually gets the focus. Even then, this would be more efficient since it would allow to generalize more code and reduce application size.


Q: How comitted are you to the current compatibility layer?

A: We assume some use cases will break even with the compatibility turned on (which would be the default in the immediate future), when possible we will try to get the compatibility working properly but we won't bend over backwards for that.


Q: Will you drop compatibility and if so when?

A: We defined the compatibility methods as deprecated, however there is no defined timeline. Once the code is available we will poll the community about the usage of compatibility and remove it when we feel migration is successful.


Q: When will this land?

A: It won't land next week. Probably.
I hope to commit by the end of the month but can't guarantee. We will also need the new LWUIT Designer to really take advantage of this feature. The delay is mostly because this change is a part of a major restructuring related to the LWUIT Designer as well and this takes quite some time...