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:[email protected]]
Envoyé : mardi 19 novembre 2013 00:39
À : [email protected]
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:[email protected]] Envoyé : lundi 18 novembre 2013 20:47
À : [email protected] Objet : Re: [dev] Build failed in Jenkins:
flex-sdk_mustella-mobile #369
On 11/18/13 11:19 AM, "Maurice Amsellem" <[email protected]>
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
