- Fixed and committed to develop branch last Mustella failure (mobile/SoftKeyboard/properties/SK_StageText_Properties SoftKeyboard_StageText_property_resizeForSoftKeyboard_false) - fixed bug spotted by Om.
Run ALL mobile mustella tests: PASS (except locale-sensitive tests) . It's good for me now. Maurice -----Message d'origine----- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 19 novembre 2013 01:47 À : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Got it: In Mustella FakeSoftKeyboard.as , line #71: if (!(comp.needsSoftKeyboard || getQualifiedClassName(comp).indexOf("StyleableStageText") > 0)) return; :-( Maurice -----Message d'origine----- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : mardi 19 novembre 2013 00:39 À : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 FYI, I am still struggling with the last Mutella failure: mobile/SoftKeyboard/properties/SK_StageText_Properties SoftKeyboard_StageText_property_resizeForSoftKeyboard_false: Failed DispatchMouseEvent(body:step 10) Timeout waiting for softKeyboardActivate from navigator.activeView.notes It's a little bit tricky, I hope to be done soon. Maurice -----Message d'origine----- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 20:47 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On 11/18/13 11:19 AM, "Maurice Amsellem" <maurice.amsel...@systar.com> wrote: > >So does the old StyleableStageText really have less memory requirement >even in that case? Not so sure... I don't know the code that well, but my understanding is that, if you don't have popups, you can save on memory. But is it enough to matter? I don't know enough to have an opinion. > >----- >That being said, we still need to keep the class, at least because it >may have been overridden by folks (Om says so) , and I am not against >keeping a few mustella tests like you suggested, to make sure it does >not break in a future version of AIR. >Will you help me select the ones that we need to keep? I don't know the code well enough to help. You saw which tests broke, you can take a few minutes to get an idea of which one or two will hit common but important code paths and keep those. > >>There may be some other things you can do to the TextField-based skins >>(masks, blends, >>filters) that we might want to keep that around as well. >Agree for the use case. >But it seems like the TextField-based skin does not behave correctly on >mobile (soft keyboard/autoCorrect not working, etc.) In this case, I >would take another approach: >With the new ScrollableStageText, you can use any DisplayObject as the >proxy, not only a bitmap (see other thread). >so we could derive a new class that would use TextField as the proxy >(and pass it all the font styles). >So of course, the filters won't be applied during editing, but that's a >common usage. It's not clear to me that's why folks use TextField. I'd say we don't do anything regarding TextField and wait for someone to complain. I think what you've done so far sounds great but I'm not sure more work for TextField will have the same payoff. -Alex
