flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Amsellem <maurice.amsel...@systar.com>
Subject RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
Date Tue, 19 Nov 2013 00:47:04 GMT
Got it:

In Mustella FakeSoftKeyboard.as , line #71:

if (!(comp.needsSoftKeyboard || getQualifiedClassName(comp).indexOf("StyleableStageText")
> 0))



-----Message d'origine-----
De : Maurice Amsellem [mailto:maurice.amsellem@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.


-----Message d'origine-----
De : Alex Harui [mailto:aharui@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.amsellem@systar.com>
>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
>>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.


View raw message