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...
HI,i am a university student from China, LWUIT framework to do very well, I'm studying how to use it, there is a doubt: there is many form use the MenuBar ,Each MenuBar's command is different ,how can i
ReplyDeleteCustomize different commands to add into MenuBar.I'm sorry,my English is poor.
big change but better :)
ReplyDeletehope solve the resource editor problem asap
re renzhe
u should learn something basic of LWUIT
or look the source code in Form class