Screen.setTransition method removed ?

5 messages - 997 views

Seems that the latest svn - version has removed Screen.setTransition - method. I need it to set the transition dynamically in my code. In my application the user can change the displayed screen by pressing left/right and I need to set the transition depending on whihch button was pressed. So the slide animation slides in the correct direction. The shortcuts - attribute for my screens is defined as "left=showScreen1(left)" where the argument tells which direction the screen should slide when doing the transition..

And also, I've been creating some new widgets by copying for example TextArea - widget as a base for my own. Problem is, that some methods which TextArea calls for it's child widgets are protected and therefore I cannot call them as I use different package. For example paintImpl - method is one such method which causes problems in TextArea.paintChildrenImpl. I know I could have just extended the TextArea - widget and use it as a base, but there are so many private methods which I cannot override that I can't get the features I want in them. I guess most private - methods in widgets should be changed to at least protected, if not public.

Right, first transitions are now define by style with the 'transition' style property. Then the best solution is to change dynamically the class of your screen, and define two class selector in you CSS file like :

screen.left { transition: slide(left); }

screen.right { transition: slide(right); }

Arg, yes, I think the only one way make Widgetvery flexibles is to turn internals methods public. But I'm not a real fan of this solution...

What sort of widget do you want to do ?

I was trying to make a custom textarea widget which would handle html - styling a bit differently. Mainly the problem is that the default textarea chokes on html which is not well formed. I just ran into problems with paintImpl method that was called from paintChildrenImpl, I guess it had something to do with scrollcontainer optimization or something like that. I guess I can go around this problem. I just copied the default textarea and made my own version of it.

Ho yes, in an ideal world the TextArea need to be rewrite, because the way to recreate a new widget for each word is not the more optimize way, but at the moment it keep the advantages of widget structure ...

Else, you're right the paintChildrenImpl is overrided because of scroll containers. But it's right too that all protected methods do not permit to extends widgets correctly. I think that the simplest way would be to turn paintImpl and paintChildrenImpl public. But I'm a bit affraid to do this.

What is your opinion on this question ?