Dan wrote: >> I'm not the OP, but i noticed some flicker while fading a window in when >> opening (see my post in the "Subclassing windows with animations?" >> thread). I solved the Problem by setting the widgets opacity to 0 >> beforehand. One could also use that method for the described problem: >> Set the opacity to 0, modify widget on "appears" and set the opacity to 1. >> >> Roman > > I wouldn't consider it a good reason for beforeAppear. The reason why > this would be critical here is that we are working with DOM element > and it is very important to know when they are rendered. However, when > the high-level animation api will come out, this kind of thing will > turn out to be unnecessary. > > I actually turned off the animations for now in my app, it turns out > it's very quirky to do at the moment. It's possible but it's longer > and more frustrating than it should be.
Hi Dan I'm sorry, i didn't say there was a reason for "beforeAppear". Your post seems to be completely unrelated to what i wrote? With the "appear" event you know perfectly well, when the DOM elements are being rendered and you can then apply your animation. Since the event seems to be fired just after the element actually appears, some flicker may occur. That's why i posted a possible solution to the Problem. At least fading a window in and out works perfectly smooth here with the described procedure. Best - Roman ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
