AW: AW: How can I check if an swf has advanced-telemetry enabled?
Hi Alex, thanks for that pointer. I guess SwfxPrinter seems to be exactly what I was looking for ... will give this a spin the next time I can free some time for Flexmojos :-) Chris Von: Alex Harui [aha...@adobe.com] Gesendet: Montag, 18. November 2013 08:05 An: dev@flex.apache.org Betreff: Re: AW: How can I check if an swf has advanced-telemetry enabled? I don't think that's right. The 4th byte is the SWF version. The enabling tool may have forced a newer SWF version, but that could happen for other reasons. I think you need to decode the SWF. There are SWF decoding classes in modules/swfutils/src/. SWFDump just calls SwfxPrinter.java. -Alex On 11/17/13 10:50 PM, christofer.d...@c-ware.de christofer.d...@c-ware.de wrote: Ok ... so I just had another look, - unpacked an swf that was not enabled - then enabled that SWF - unpacked that content - loaded both files in a text-compare tool So it seems that the difference is simplywithin the first 7 bytes Not Enabled: FWS0J+ Enabed: FWS4J+ (There seems to be some sort of line break after the FWS) So can I go and hunt for the one different byte to detect if a file is enabled? Chris -Ursprüngliche Nachricht- Von: Darrell Loverin [mailto:darrell.love...@gmail.com] Gesendet: Montag, 18. November 2013 02:18 An: dev@flex.apache.org Betreff: Re: How can I check if an swf has advanced-telemetry enabled? Oh, I see, Justin added it to swfutils. I was looking for it in falcon since this is where I had added the support but I don't see the code in Apache Flex's falcon. -Darrell On Sun, Nov 17, 2013 at 3:46 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, I believe there was a new tag added to the swf to enable telemetry. I don't see this tag supported in Apache Flex. The new tag in the swf is supported in Apache Flex (4.10 and 4.11) otherwise how else could we support it? The tags value is 93, so you can look for that or just use swfdump, if the swf has advanced telemetry turned on it will show this: EnableTelemetry advancedTelemetry='true'/ Thanks, Justin
Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
On Sun, Nov 17, 2013 at 11:56 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Checked the .bad.png. All are the same: sub-pixel shift when the action bar contains a text input. This is because the text input now displays a bitmap instead of the StageText. Although they have the same extent (because the bitmap is supposed to be a pixel copy of the stageText), FP is probably displaying them at a slightly different position. So it's not wrong in my sense. I will analyze the difference in the DL dump. Or maybe I should update the baseline png with the new ones ? +1 for updating the baselines. This is how it will appear to the end user, so that should be reflected in our test cases too. Thanks, Om Maurice -Message d'origine- De : Maurice Amsellem Envoyé : lundi 18 novembre 2013 08:49 À : 'Erik de Bruin' Cc : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Yes, but didn't run all the mobile tests, only TextInput, TextArea and StageText. -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : lundi 18 novembre 2013 08:47 À : Maurice Amsellem Cc : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Hi, Playing 'bad cop' here: did you run the mobile Mustella tests before pushing the commits? EdB On Mon, Nov 18, 2013 at 8:41 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Analysing the failures... -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : lundi 18 novembre 2013 05:38 À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella-mobile #369 See http://localhost:8080/job/flex-sdk_mustella-mobile/369/changes Changes: [erik] Updated jenkins.sh for Mustella VM with latest FP and AIR betas [jmclean] Add support for FP 12 and AIR 4 beta. [maurice.amsellem] Tentative FIX of FLEX-33166 Mobile TextInput with native StageTextInput cannot be included in scrollable forms -- [...truncated 16221 lines...] [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs [java] Launching: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs\ActionBar.xml -screensize 640x960:640x960 -profile mobileDevice -XscreenDPI 240 Launching: C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs\ActionBar.xml [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs [java] time: 23:37:03.106 [java] waited 1500 [java] ClobberProcess, it was already null [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mobile/components/ActionBar/styles/baselines/ActionBar_TitleDisplay_TextDecoration@android_240ppi.png.bad.png.xmllength: 41774 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mobile/components/ActionBar/styles/baselines/ActionBar_TitleDisplay_TextDecoration@android_240ppi.png.bad.pnglength: 2375 [java] FAIL: mobile/components/ActionBar/styles/ActionBar_Styles ActionBar_TitleDisplay_TextDecoration [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mobile/components/ActionBar/styles/baselines/ActionBar_FocusColor@android_240ppi.png.bad.pnglength: 1021 [java] FAIL: mobile/components/ActionBar/styles/ActionBar_Styles ActionBar_FocusColor [java] SCRIPTDONE! 23:37:10.019 [java] GET /ScriptComplete?0 HTTP/1.1 [java] Before Wait loop 23:37:10.019 waiting = 0 [java] After Wait loop 23:37:10.019 waiting = 0 [java] clobberProcess false [java] Total Results so far: 3 [java] removing the xml app file [java] Grab log, do parse = false [java] Grabbing the log from: C:\Users\ApacheFlex\AppData/Roaming\Macromedia/Flash Player/Logs/flashlog.txt to: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs\ActionBar.log [java] apollo adj with : C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs\ActionBarMain2.swf [java] apollo adj thinks it's a swf [java] writing Apollo file! [java] full swf is C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\components\ActionBar\swfs\ActionBarMain2.swf [java] post ApolloAdjuster:
RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
Updated the mustella baselines for mobile/components/ActionBar failing tests. Note: the bitmaps only differ by a few pixels, and the xml DL files have the same coordinates and excent but bitmap instead of stageText, something like: spark.skins.mobile.StageTextInputSkin width=200 height=53 spark.components.supportClasses.StyleableStageText x=9 y=9 width=182 height=35/ [...] /spark.skins.mobile.StageTextInputSkin (StyleableStageText includes StageText , but it does not show in the DL for some reason...) Changed to: spark.skins.mobile.ScrollingStageTextInputSkin width=200 height=53 spark.components.supportClasses.ScrollableStageText x=9 y=9 width=182 height=35 flash.display.Bitmap width=182 height=35/ /spark.components.supportClasses.ScrollableStageText [...] /spark.skins.mobile.ScrollingStageTextInputSkin So it's good for me... Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : lundi 18 novembre 2013 09:06 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On Sun, Nov 17, 2013 at 11:56 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Checked the .bad.png. All are the same: sub-pixel shift when the action bar contains a text input. This is because the text input now displays a bitmap instead of the StageText. Although they have the same extent (because the bitmap is supposed to be a pixel copy of the stageText), FP is probably displaying them at a slightly different position. So it's not wrong in my sense. I will analyze the difference in the DL dump. Or maybe I should update the baseline png with the new ones ? +1 for updating the baselines. This is how it will appear to the end +user, so that should be reflected in our test cases too. Thanks, Om Maurice -Message d'origine- De : Maurice Amsellem Envoyé : lundi 18 novembre 2013 08:49 À : 'Erik de Bruin' Cc : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Yes, but didn't run all the mobile tests, only TextInput, TextArea and StageText. -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : lundi 18 novembre 2013 08:47 À : Maurice Amsellem Cc : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Hi, Playing 'bad cop' here: did you run the mobile Mustella tests before pushing the commits? EdB On Mon, Nov 18, 2013 at 8:41 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Analysing the failures... -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : lundi 18 novembre 2013 05:38 À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella-mobile #369 See http://localhost:8080/job/flex-sdk_mustella-mobile/369/changes Changes: [erik] Updated jenkins.sh for Mustella VM with latest FP and AIR betas [jmclean] Add support for FP 12 and AIR 4 beta. [maurice.amsellem] Tentative FIX of FLEX-33166 Mobile TextInput with native StageTextInput cannot be included in scrollable forms -- [...truncated 16221 lines...] [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs [java] Launching: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs\ActionBar.xml -screensize 640x960:640x960 -profile mobileDevice -XscreenDPI 240 Launching: C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs\ActionBar.xml [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs [java] time: 23:37:03.106 [java] waited 1500 [java] ClobberProcess, it was already null [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mob ile/components/ActionBar/styles/baselines/ActionBar_TitleDisplay_TextD ecoration@android_240ppi.png.bad.png.xmllength: 41774 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mob ile/components/ActionBar/styles/baselines/ActionBar_TitleDisplay_TextD ecoration@android_240ppi.png.bad.pnglength: 2375 [java] FAIL: mobile/components/ActionBar/styles/ActionBar_Styles ActionBar_TitleDisplay_TextDecoration [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mob ile/components/ActionBar/styles/baselines/ActionBar_FocusColor@android _240ppi.png.bad.pnglength: 1021 [java] FAIL:
RE: Air Stage Text Issue
I can try to ask the engineer who worked on it to see if he remembers Hi Alex, Do you think you will be able to reach the above mentioned engineer in the coming days, to know why StyleableStageText was implemented that way ? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 16 novembre 2013 19:32 À : dev@flex.apache.org Objet : Re: Air Stage Text Issue I can try to ask the engineer who worked on it to see if he remembers, but I would guess the following: 1) There was hope that AIR would provide a solution 2) I'm not sure proxying would handle text selection. 3) I'm not sure proxying would handle partially occluded text inputs. You're welcome to take a shot at it. Adobe generally didn't like half-baked solutions so if it there was no solution for partially-occluded text inputs it wouldn't provide a solution at all, but maybe it is worth offering a solution for folks who won't ever partially occlude their text inputs (which is probably a lot of folks). But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure. -Alex On 11/16/13 5:17 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Hi, I am currently working on the issue about StageTextInput not scrolling on mobile: https://issues.apache.org/jira/browse/FLEX-33166 Debugging the SDK source code, it appears that proxying the StageTextInput with a bitmap is already in place (see class StyleableStageText). However, the proxy bitmap is shown in only very specific situations: - a stage animation that contains the stage text is playing (example: Touch throw animation, that happens when you *release* your finger after swiping ) - popup is opened , in which case all text input below in the z-order are proxied to bitmaps Another rather radical approach, which has been suggested by some ( DarkStone, Flexicious), would be to always display a StageText as a proxy bitmap when it's visible, and to show the StageText only when typing text via the soft keyboard. It's hard for me to believe that the Adobe SDK team went into all the pain of implementing the bitmap proxying, and the complex popup depth calculations (cf. StyleableStageText 3000+ lines of code) and didn't think about such a simple approach. So there must be something else! Some ideas come to mind: - memory concerns: maintaining bitmap proxies for all visible text inputs (and text areas), especially on high resolution displays, can be very costly. - time: maybe Flex was stopped at Adobe before this approach could be implemented, and TI was left in an intermediate state... Or maybe, they didn't see the scrolling issue... nobody is perfect. Does someone know ? Maurice -Message d'origine- De : DarkStone [mailto:darkst...@163.com] Envoyé : mercredi 30 octobre 2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text Issue Hi Naveen, I haven't got time to implement it yet. But I figure it out a better solution: 1. Create a class named VisualStageText which extends SpriteVisualElement class and implements IEditableText interface. 2. In the VisualStageText class implementation, define a private variable stageText:StageText, use it to implement IEditableText yourself, and also define a private variable snapshot:Bitmap. 3. Listen for VisualStageText instance's Event.ACTIVATE, Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other interaction relative events to detect user interactions. 4. When the user is currently interacting with VisualStageText, you need to hide the snapshot and show the stageText: snapshot.parent ? removeChild(snapshot) : null; snapshot.bitmapData.dispose(); snapshot.bitmapData = null; stageText.stage = stage; stageText.viewPort = new Rectangle(...); 5. When the user is not interacting with VisualStageText, you need to take a snapshot of the stageText, then hide the stageText and display the snapshot: var bd:BitmapData = new BitmapData(stageText.viewPort.width, stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd); snapshot.bitmapData = bd; stageText.stage = null; addChild(snapshot); Well this is it, this is the core concept of how to do a Flex version StageText, you can use the VisualStageText as a MXML tag, and bind it to the skinpart of the spark TextInput (or TextArea)'s textDisplay:IEditableText. I plan to implement my VisualStageText at the end of this year, but if you can't wait you can do it by yourself, good luck : ) DarkStone 2013-10-30 At 2013-10-30 01:44:33,Naveen2803 naveen.malhotr...@gmail.com wrote: Hi DarkStone, Thank you for your post. Can you please share the code for the same as I am little confused on how to achieve this. Thanks is Advance -- View this message in context: http://apache-flex-development.247.n4.nabble.com/Air-Stage-Text-Is s ue-tp30223p31670.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Mobile TextInput Implementation status
Memory profiling of the new skins:
It's as expected: alloc memory = pixel width x pixel height x 4bytes per
pixel.
First figure is for iPad , second is for iPad retina.
- 25KB / 100 KB of bitmap memory allocated for a single line TI with default
size
- ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
- 3 MB / 12 MB for a full-page TA = in this case, it's better to use the old
skins.
The bitmap is allocated while the TI is added to the stage, and disposed when
it's removed from the stage
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 02:10
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
1) to help debug if something goes wrong on Android, you can set the following
mx_internal flag:
ScrollableStageText.debugProxyImage = true;
It will display the proxy bitmaps in magenta background.
2) proxy methods in ScrollableStageText has been abstracted on purpose to
DisplayObject instead of Bitmap.
This is so that one could override the class to use another proxy (eg.
StyleableTextField) which is less memory consuming than bitmaps.
In wich case, you will have to override:
createProxy
updateProxy
disposeProxy
3) StageTextSkinBase inner textDisplay creation method is externalized so that
it can be customized.
Example for ScrollableStageTextInputSkin:
override protected function createTextDisplay():IStyleableEditableText
{
return new ScrollableStageText(multiline);
}
That way, you can derive from existing skins, instead of monkey patching the
default skin, if you only need to change the internal editable text class.
Note also that displayText is now of type IStyleableEditableText, instead of
StyleableStageText, for the same purpose.
Regards,
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 01:49
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Run mustella tests:
Mobile/Components/TextInput
Mobile/components/TextArea
Mobile/StageText
All pass.
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 01:11
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Hi, I have committed and pushed tentative fix for
https://issues.apache.org/jira/browse/FLEX-33166
Tested on iPad 2 / 3.
Not tested on Android.
I couldn't run mustella mobile tests. For some reason, they are broken on my
machine ( says: Passes: 0 / Fails: 0).
The new skins are now the defaults for TextInput and TextArea on mobile:
TextInput skinClass = spark.skins.mobile.ScrollingStageTextInputSkin
TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
The old skins are still there, under the same name.
Please review and tests, and this is a sensitive change...
Your comments and feedback are welcome.
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 00:08
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Founds some bugs, so I won't commit until they are fixed...
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org Objet : RE:
Mobile TextInput Implementation status
I can help out with Android testing.
Thanks
Should I wait for the nightly or are these fixes on a branch? Nightly would
be preferable so as to allow more people to test the fix.
I will push to the develop/ so that they be in the nightly
It would be better to keep the old one around with the same name. Folks might
have subclassed it to build their own implementations.
What about :
ScrollableStageText
ScrollableStageTextInputSkin
For the new classes ?
Maurice
-Message d'origine-
De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash
Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À : dev@flex.apache.org
Objet : Re: Mobile TextInput Implementation status
On Nov 17, 2013 10:56 AM, Maurice Amsellem maurice.amsel...@systar.com
wrote:
Hi,
Here is a brief status of the implementation of Mobile Text Input,
along
with some questions:
Implementation overview:
The change is mainly on the class StyleableStageText, which now takes
the
opposite approach than the previous one:
- display proxy image bitmap by default
- display StageText only when editing
StageTextInputSkin/StageTextAreaSkin has been modified to use this
class
- to make it easier to change StageTextInputSkin internal
StyleableStageText component, the variable textDisplay is now of type
IStyleableEditText
Behavior changes:
- scrolling and overlapping of text is well managed , as it always
uses
the bitmap proxy, which is a Flex component: all the text inputs are scrolling
Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
Sorry, I haven't had time to follow the details. The baselines should not be removed if they are correct for StageTextInputSkin. We may need additional tests for the new skin classes. If you want to rename tests, and reorganize as well, that's fine, but my understanding is that the code paths these tests used to verify are still there. -Alex On 11/18/13 3:59 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Updated the mustella baselines for mobile/components/ActionBar failing tests. Note: the bitmaps only differ by a few pixels, and the xml DL files have the same coordinates and excent but bitmap instead of stageText, something like: spark.skins.mobile.StageTextInputSkin width=200 height=53 spark.components.supportClasses.StyleableStageText x=9 y=9 width=182 height=35/ [...] /spark.skins.mobile.StageTextInputSkin (StyleableStageText includes StageText , but it does not show in the DL for some reason...) Changed to: spark.skins.mobile.ScrollingStageTextInputSkin width=200 height=53 spark.components.supportClasses.ScrollableStageText x=9 y=9 width=182 height=35 flash.display.Bitmap width=182 height=35/ /spark.components.supportClasses.ScrollableStageText [...] /spark.skins.mobile.ScrollingStageTextInputSkin So it's good for me... Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : lundi 18 novembre 2013 09:06 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On Sun, Nov 17, 2013 at 11:56 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Checked the .bad.png. All are the same: sub-pixel shift when the action bar contains a text input. This is because the text input now displays a bitmap instead of the StageText. Although they have the same extent (because the bitmap is supposed to be a pixel copy of the stageText), FP is probably displaying them at a slightly different position. So it's not wrong in my sense. I will analyze the difference in the DL dump. Or maybe I should update the baseline png with the new ones ? +1 for updating the baselines. This is how it will appear to the end +user, so that should be reflected in our test cases too. Thanks, Om Maurice -Message d'origine- De : Maurice Amsellem Envoyé : lundi 18 novembre 2013 08:49 À : 'Erik de Bruin' Cc : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Yes, but didn't run all the mobile tests, only TextInput, TextArea and StageText. -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : lundi 18 novembre 2013 08:47 À : Maurice Amsellem Cc : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Hi, Playing 'bad cop' here: did you run the mobile Mustella tests before pushing the commits? EdB On Mon, Nov 18, 2013 at 8:41 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Analysing the failures... -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : lundi 18 novembre 2013 05:38 À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella-mobile #369 See http://localhost:8080/job/flex-sdk_mustella-mobile/369/changes Changes: [erik] Updated jenkins.sh for Mustella VM with latest FP and AIR betas [jmclean] Add support for FP 12 and AIR 4 beta. [maurice.amsellem] Tentative FIX of FLEX-33166 Mobile TextInput with native StageTextInput cannot be included in scrollable forms -- [...truncated 16221 lines...] [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs [java] Launching: [java] C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs\ActionBar.xml -screensize 640x960:640x960 -profile mobileDevice -XscreenDPI 240 Launching: C:\ApacheFlex\dependencies\AdobeAIRSDK\3.7\bin\adl.exe C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs\ActionBar.xml [java] USING directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mob ile\components\ActionBar\swfs [java] time: 23:37:03.106 [java] waited 1500 [java] ClobberProcess, it was already null [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mob ile/components/ActionBar/styles/baselines/ActionBar_TitleDisplay_TextD ecoration@android_240ppi.png.bad.png.xmllength: 41774 [java] Wrote file: c:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/mob
RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
Sorry, I haven't had time to follow the details. The baselines should not be removed if they are correct for StageTextInputSkin. We may need additional tests for the new skin classes. If you want to rename tests, and reorganize as well, that's fine, but my understanding is that the code paths these tests used to verify are still there. Hi Alex, the new skins are now the default ones (set in mobile theme default.css), so the default behavior is using the new skins. That's why I had to change the baselines (sub-pixel differences, because of the added Bitmap). I left the old skins (StageTextInputSkin and StageTextAreaSkin) in case they are needed, but they are not the default ones anymore: they must be set explicitly. So from mustella standpoint, it's all good for me. Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 17:09 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Sorry, I haven't had time to follow the details. The baselines should not be removed if they are correct for StageTextInputSkin. We may need additional tests for the new skin classes. If you want to rename tests, and reorganize as well, that's fine, but my understanding is that the code paths these tests used to verify are still there. -Alex On 11/18/13 3:59 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Updated the mustella baselines for mobile/components/ActionBar failing tests. Note: the bitmaps only differ by a few pixels, and the xml DL files have the same coordinates and excent but bitmap instead of stageText, something like: spark.skins.mobile.StageTextInputSkin width=200 height=53 spark.components.supportClasses.StyleableStageText x=9 y=9 width=182 height=35/ [...] /spark.skins.mobile.StageTextInputSkin (StyleableStageText includes StageText , but it does not show in the DL for some reason...) Changed to: spark.skins.mobile.ScrollingStageTextInputSkin width=200 height=53 spark.components.supportClasses.ScrollableStageText x=9 y=9 width=182 height=35 flash.display.Bitmap width=182 height=35/ /spark.components.supportClasses.ScrollableStageText [...] /spark.skins.mobile.ScrollingStageTextInputSkin So it's good for me... Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : lundi 18 novembre 2013 09:06 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On Sun, Nov 17, 2013 at 11:56 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Checked the .bad.png. All are the same: sub-pixel shift when the action bar contains a text input. This is because the text input now displays a bitmap instead of the StageText. Although they have the same extent (because the bitmap is supposed to be a pixel copy of the stageText), FP is probably displaying them at a slightly different position. So it's not wrong in my sense. I will analyze the difference in the DL dump. Or maybe I should update the baseline png with the new ones ? +1 for updating the baselines. This is how it will appear to the end +user, so that should be reflected in our test cases too. Thanks, Om Maurice -Message d'origine- De : Maurice Amsellem Envoyé : lundi 18 novembre 2013 08:49 À : 'Erik de Bruin' Cc : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Yes, but didn't run all the mobile tests, only TextInput, TextArea and StageText. -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : lundi 18 novembre 2013 08:47 À : Maurice Amsellem Cc : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Hi, Playing 'bad cop' here: did you run the mobile Mustella tests before pushing the commits? EdB On Mon, Nov 18, 2013 at 8:41 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Analysing the failures... -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : lundi 18 novembre 2013 05:38 À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella-mobile #369 See http://localhost:8080/job/flex-sdk_mustella-mobile/369/changes Changes: [erik] Updated jenkins.sh for Mustella VM with latest FP and AIR betas [jmclean] Add support for FP 12 and AIR 4 beta. [maurice.amsellem] Tentative FIX of FLEX-33166 Mobile TextInput with native StageTextInput cannot be included in scrollable forms -- [...truncated 16221 lines...] [java] derived directory: C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mo b ile\components\ActionBar\swfs [java] Launching: [java]
RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
the code paths these tests used to verify are still there Sorry, I send the email too quick. In fact, the only visual differences between old and new baselines are because of sub-pixel diff. The rendering is the same. And the scrolling behavior (that is the only changed behavior) is not tested. If it was, it would have failed. WDYT? Maurice -Message d'origine- De : Maurice Amsellem Envoyé : lundi 18 novembre 2013 17:23 À : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Sorry, I haven't had time to follow the details. The baselines should not be removed if they are correct for StageTextInputSkin. We may need additional tests for the new skin classes. If you want to rename tests, and reorganize as well, that's fine, but my understanding is that the code paths these tests used to verify are still there. Hi Alex, the new skins are now the default ones (set in mobile theme default.css), so the default behavior is using the new skins. That's why I had to change the baselines (sub-pixel differences, because of the added Bitmap). I left the old skins (StageTextInputSkin and StageTextAreaSkin) in case they are needed, but they are not the default ones anymore: they must be set explicitly. So from mustella standpoint, it's all good for me. Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 17:09 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Sorry, I haven't had time to follow the details. The baselines should not be removed if they are correct for StageTextInputSkin. We may need additional tests for the new skin classes. If you want to rename tests, and reorganize as well, that's fine, but my understanding is that the code paths these tests used to verify are still there. -Alex On 11/18/13 3:59 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Updated the mustella baselines for mobile/components/ActionBar failing tests. Note: the bitmaps only differ by a few pixels, and the xml DL files have the same coordinates and excent but bitmap instead of stageText, something like: spark.skins.mobile.StageTextInputSkin width=200 height=53 spark.components.supportClasses.StyleableStageText x=9 y=9 width=182 height=35/ [...] /spark.skins.mobile.StageTextInputSkin (StyleableStageText includes StageText , but it does not show in the DL for some reason...) Changed to: spark.skins.mobile.ScrollingStageTextInputSkin width=200 height=53 spark.components.supportClasses.ScrollableStageText x=9 y=9 width=182 height=35 flash.display.Bitmap width=182 height=35/ /spark.components.supportClasses.ScrollableStageText [...] /spark.skins.mobile.ScrollingStageTextInputSkin So it's good for me... Maurice -Message d'origine- De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash Muppirala Envoyé : lundi 18 novembre 2013 09:06 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On Sun, Nov 17, 2013 at 11:56 PM, Maurice Amsellem maurice.amsel...@systar.com wrote: Checked the .bad.png. All are the same: sub-pixel shift when the action bar contains a text input. This is because the text input now displays a bitmap instead of the StageText. Although they have the same extent (because the bitmap is supposed to be a pixel copy of the stageText), FP is probably displaying them at a slightly different position. So it's not wrong in my sense. I will analyze the difference in the DL dump. Or maybe I should update the baseline png with the new ones ? +1 for updating the baselines. This is how it will appear to the end +user, so that should be reflected in our test cases too. Thanks, Om Maurice -Message d'origine- De : Maurice Amsellem Envoyé : lundi 18 novembre 2013 08:49 À : 'Erik de Bruin' Cc : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Yes, but didn't run all the mobile tests, only TextInput, TextArea and StageText. -Message d'origine- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : lundi 18 novembre 2013 08:47 À : Maurice Amsellem Cc : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 Hi, Playing 'bad cop' here: did you run the mobile Mustella tests before pushing the commits? EdB On Mon, Nov 18, 2013 at 8:41 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Analysing the failures... -Message d'origine- De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com] Envoyé : lundi 18 novembre 2013 05:38 À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice Amsellem Objet : Build failed in Jenkins: flex-sdk_mustella-mobile #369 See http://localhost:8080/job/flex-sdk_mustella-mobile/369/changes Changes:
RE: Build failed in Jenkins: flex-sdk_mustella-mobile #370
Analyzing the failure.
Maurice
-Message d'origine-
De : flex.muste...@gmail.com [mailto:flex.muste...@gmail.com]
Envoyé : lundi 18 novembre 2013 17:39
À : comm...@flex.apache.org; e...@ixsoftware.nl; jmcl...@apache.org; Maurice
Amsellem
Objet : Build failed in Jenkins: flex-sdk_mustella-mobile #370
See http://localhost:8080/job/flex-sdk_mustella-mobile/370/changes
Changes:
[jmclean] Added new FP and AIR support notes
[jmclean] FLEX-33912 Added Chinese translation - checked via google translate
[maurice.amsellem] UPDATED - Tentative FIX of FLEX-33166 Mobile TextInput with
native StageTextInput cannot be included in scrollable forms
--
[...truncated 15973 lines...]
setup_windows:
[echo] doing windows setup
[echo] homepath: C:\Users\ApacheFlex
[echo] trace output file: 1
[echo] player is
C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer11-9_debugsa_win_32.exe
setup_linux:
db_time:
[mkdir] Created dir:
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tmp
[echo] db_time=2013/11/18 11:38:36
get_mobile_data:
[getdevicespecstask] Skipping mobile device setup; win is not a mobile device,
maybe emulating target OS android on desktop.
device_fail:
handle_mobile_config:
[echo] os: ${os}
[echo] target_os_name: android
[echo] os_version: ${os_version}
[echo] device_name: win
[echo] get_results_from_log: false
[echo] step_timeout: ${step_timeout}
[echo] run_mobile_tests: true
[echo] use_android_runner: ${use_android_runner}
[echo] use_ios_runner: ${use_ios_runner}
[echo] use_qnx_runner: ${use_qnx_runner}
[echo] exclude_filename:
C:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/ExcludeList${os}.txt
[echo] have_air_interpreter is ${have_air_interpreter}
[echo] have_air_packager is ${have_air_packager}
[echo] have_air_adt_jar is true
[echo] have_air_android_runtime is ${have_air_android_runtime}
[echo] need_air_android is ${need_air_android}
[echo] need_air_ios is ${need_air_ios}
[echo] need_to_show_air_ios_fail_message is
${need_to_show_air_ios_fail_message}
[echo] need_to_fetch_air_ios is ${need_to_fetch_air_ios}
show_air_ios_fail_message:
show_air_android_fail_message:
fetch_air_ios:
fetch_qnx_sdk:
echo-browser:
echo-apollo:
[echo] use_apollo=true
[echo] apollo_location is C:\ApacheFlex\dependencies\AdobeAIRSDK\3.9
setup:
[echo] player is
C:\ApacheFlex\dependencies\FlashPlayer_Debug\flashplayer11-9_debugsa_win_32.exe
[echo] fileset: mobile\SoftKeyboard\properties\SK_StageText_Properties.mxml
setbuildID:
[echo] Target file was:
C:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/successfulBuild.properties
[echo] ${server}
setHostName:
getConfigId:
getActualRunId:
getRunId:
compilemustellaswc:
[exec] Loading configuration file
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\frameworks\flex-config.xml
[exec]
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\mustella.swc
(94612 bytes)
realCompile:
build_shell_set:
[echo] shell_file_mxml_equivs is
,mobile/SoftKeyboard/properties/SK_StageText_Properties.sh
[echo] mxml_equiv_shells is ${mxml_equiv_shells}
[echo] tmp.sdk.mustella.scripts2 is
chmod_shells:
[echo] changing user shell files to executable
shells:
[exec] done with pre compile step
[java] exclude_filename:
C:/jenkins_slave/workspace/flex-sdk_mustella-mobile/mustella/tests/ExcludeList${os}.txt
[java] os_version: ${os_version}
[java] target_os_name: android
[java] device_name: win
[java] result_include: -includes=SendResultsToRunner
[java] created
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\as3\src\mustella\MobileConfig.as
[java] nothing left to do
[java] Choosing local runner bitmap save
[java] okey doke, going to compile
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SoftKeyboard\SWFs\SKStageText.mxml
[java] Loading configuration file
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\frameworks\airmobile-config.xml
[java]
C:\jenkins_slave\workspace\flex-sdk_mustella-mobile\mustella\tests\mobile\SoftKeyboard\swfs\SKStageText.swf
(1701593 bytes)
[java] All done with the compile
[java] leaving the compile, elapsed: 9
[java] ...via exit
[echo] compileswfs jreturn is 0
do_fail:
compileswfs:
getExcludes:
getExcludeIds:
populateExcludeTable:
[echo] populate exclude, got this for db time: 2013/11/18 11:38:36
justrun:
delete_cache:
[echo] delete cache: /Users/ApacheFlex/Library/Caches/Adobe/Flash
Player/AssetCache
delete_cache:
[echo] delete cache: /Users/ApacheFlex/AppData/Roaming/Adobe/Flash
Player/AssetCache
[delete] Deleting directory C:\Users\ApacheFlex\AppData\Roaming\Adobe\Flash
Player\AssetCache\UUNMD6SN
[delete]
Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
On 11/18/13 8:25 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: the code paths these tests used to verify are still there Sorry, I send the email too quick. In fact, the only visual differences between old and new baselines are because of sub-pixel diff. The rendering is the same. And the scrolling behavior (that is the only changed behavior) is not tested. If it was, it would have failed. WDYT? I haven't seen the image diffs, so I don't know what you mean by sub-pixel. There are two common cases: 1) a few pixels are different in corners and edges because the anti-aliasing chose slightly different values, and 2) everything moved by less than a pixel, in which case the diffs usually look like the outlines of entire characters in any fonts. For 1), it might be sufficient to use png.xml files, for 2) you have to worry that even a sub-pixel shift will be noticed by someone who has pixel-perfected their UI. Also, I may not be understanding the situation fully, but it now sounds like there are no tests for StageTextInputSkin? I was going to recommend copying a few tests (probably not all) and setting them up to use StageTextInputSkin in which case some of the old baselines would still be valid. -Alex
RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
I haven't seen the image diffs, so I don't know what you mean by sub-pixel. There are two common cases: 1) a few pixels are different in corners and edges because the anti-aliasing chose slightly different values, You are correct, I have seen the diffs as well and there are a few different black pixels in the edges. That's what I called sub-pixel mistakenly, to mean that it was subtle differences caused by anti-aliasing. Sorry for the miswording (and don't forget I am not a native English speaker ;-) ) and 2) everything moved by less than a pixel, in which case the diffs usually look like the outlines of entire characters in any fonts. That ones are really sub-pixels shifts. Anyway, I checked the xml DL, and the coordinates/extents are exactly the same, expect that the new skin has a bitmap, so there is no computation error and nothing we can really do about that, apart from updating the baselines. but it now sounds like there are no tests for StageTextInputSkin? I was going to recommend copying a few tests (probably not all) and setting them up to use StageTextInputSkin in which case some of the old baselines would still be valid. Ideally, you are correct, that should be done. I will do it when I have some spare time (or if there is any volunteer). But maybe we should consider StageTextInputSkin as deprecated, because of its buggy behavior (scrolling, occlusion, etc.). So we leave it in the code for compatibility, but does it really need mustella tests ? On a side note, I don't like the idea of providing 3 skins for achieving the same result [ Editing Text in a mobile device], not because there are 3 uses cases, but because of technical limitations of each. I would really prefer to have ONE skin, improve/fix it until it behaves well in all situations, and put the other ones in the deprecated status. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 18:22 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On 11/18/13 8:25 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: the code paths these tests used to verify are still there Sorry, I send the email too quick. In fact, the only visual differences between old and new baselines are because of sub-pixel diff. The rendering is the same. And the scrolling behavior (that is the only changed behavior) is not tested. If it was, it would have failed. WDYT? I haven't seen the image diffs, so I don't know what you mean by sub-pixel. There are two common cases: 1) a few pixels are different in corners and edges because the anti-aliasing chose slightly different values, and 2) everything moved by less than a pixel, in which case the diffs usually look like the outlines of entire characters in any fonts. For 1), it might be sufficient to use png.xml files, for 2) you have to worry that even a sub-pixel shift will be noticed by someone who has pixel-perfected their UI. Also, I may not be understanding the situation fully, but it now sounds like there are no tests for StageTextInputSkin? I was going to recommend copying a few tests (probably not all) and setting them up to use StageTextInputSkin in which case some of the old baselines would still be valid. -Alex
RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
Sorry again...I understood that you have seen the diffs and found the two use cases. Actually, I have only seen the first case : a few gray pixels to the edge of the TI round rect border. Maurice -Message d'origine- De : Maurice Amsellem [mailto:maurice.amsel...@systar.com] Envoyé : lundi 18 novembre 2013 18:38 À : dev@flex.apache.org Objet : RE: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 I haven't seen the image diffs, so I don't know what you mean by sub-pixel. There are two common cases: 1) a few pixels are different in corners and edges because the anti-aliasing chose slightly different values, You are correct, I have seen the diffs as well and there are a few different black pixels in the edges. That's what I called sub-pixel mistakenly, to mean that it was subtle differences caused by anti-aliasing. Sorry for the miswording (and don't forget I am not a native English speaker ;-) ) and 2) everything moved by less than a pixel, in which case the diffs usually look like the outlines of entire characters in any fonts. That ones are really sub-pixels shifts. Anyway, I checked the xml DL, and the coordinates/extents are exactly the same, expect that the new skin has a bitmap, so there is no computation error and nothing we can really do about that, apart from updating the baselines. but it now sounds like there are no tests for StageTextInputSkin? I was going to recommend copying a few tests (probably not all) and setting them up to use StageTextInputSkin in which case some of the old baselines would still be valid. Ideally, you are correct, that should be done. I will do it when I have some spare time (or if there is any volunteer). But maybe we should consider StageTextInputSkin as deprecated, because of its buggy behavior (scrolling, occlusion, etc.). So we leave it in the code for compatibility, but does it really need mustella tests ? On a side note, I don't like the idea of providing 3 skins for achieving the same result [ Editing Text in a mobile device], not because there are 3 uses cases, but because of technical limitations of each. I would really prefer to have ONE skin, improve/fix it until it behaves well in all situations, and put the other ones in the deprecated status. WDYT? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 18:22 À : dev@flex.apache.org Objet : Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369 On 11/18/13 8:25 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: the code paths these tests used to verify are still there Sorry, I send the email too quick. In fact, the only visual differences between old and new baselines are because of sub-pixel diff. The rendering is the same. And the scrolling behavior (that is the only changed behavior) is not tested. If it was, it would have failed. WDYT? I haven't seen the image diffs, so I don't know what you mean by sub-pixel. There are two common cases: 1) a few pixels are different in corners and edges because the anti-aliasing chose slightly different values, and 2) everything moved by less than a pixel, in which case the diffs usually look like the outlines of entire characters in any fonts. For 1), it might be sufficient to use png.xml files, for 2) you have to worry that even a sub-pixel shift will be noticed by someone who has pixel-perfected their UI. Also, I may not be understanding the situation fully, but it now sounds like there are no tests for StageTextInputSkin? I was going to recommend copying a few tests (probably not all) and setting them up to use StageTextInputSkin in which case some of the old baselines would still be valid. -Alex
Re: [dev] Build failed in Jenkins: flex-sdk_mustella-mobile #369
On 11/18/13 9:38 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Anyway, I checked the xml DL, and the coordinates/extents are exactly the same, expect that the new skin has a bitmap, so there is no computation error and nothing we can really do about that, apart from updating the baselines. OK, then it is probably ok to update the baselines. On a side note, I don't like the idea of providing 3 skins for achieving the same result [ Editing Text in a mobile device], not because there are 3 uses cases, but because of technical limitations of each. I would really prefer to have ONE skin, improve/fix it until it behaves well in all situations, and put the other ones in the deprecated status. WDYT? Well, if you think nobody will ever need StageTextInputSkin, then your version should simply replace it. If you think there may be performance or memory trade-offs where someone will want the old one because they aren't scrolling their StageText's then we should keep them. 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. -Alex
RE: Air Stage Text Issue
Thank you for the information -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : lundi 18 novembre 2013 18:58 À : dev@flex.apache.org Objet : Re: Air Stage Text Issue I asked him today. He pretty much confirmed what I said. The AIR team was in the process of trying to provide the solution, so we didn't invest time on it. -Alex On 11/18/13 7:41 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: I can try to ask the engineer who worked on it to see if he remembers Hi Alex, Do you think you will be able to reach the above mentioned engineer in the coming days, to know why StyleableStageText was implemented that way ? Maurice -Message d'origine- De : Alex Harui [mailto:aha...@adobe.com] Envoyé : samedi 16 novembre 2013 19:32 À : dev@flex.apache.org Objet : Re: Air Stage Text Issue I can try to ask the engineer who worked on it to see if he remembers, but I would guess the following: 1) There was hope that AIR would provide a solution 2) I'm not sure proxying would handle text selection. 3) I'm not sure proxying would handle partially occluded text inputs. You're welcome to take a shot at it. Adobe generally didn't like half-baked solutions so if it there was no solution for partially-occluded text inputs it wouldn't provide a solution at all, but maybe it is worth offering a solution for folks who won't ever partially occlude their text inputs (which is probably a lot of folks). But before you go work on that, can you look at the most recent mustella failures? I think there is a new DataGrid failure. -Alex On 11/16/13 5:17 AM, Maurice Amsellem maurice.amsel...@systar.com wrote: Hi, I am currently working on the issue about StageTextInput not scrolling on mobile: https://issues.apache.org/jira/browse/FLEX-33166 Debugging the SDK source code, it appears that proxying the StageTextInput with a bitmap is already in place (see class StyleableStageText). However, the proxy bitmap is shown in only very specific situations: - a stage animation that contains the stage text is playing (example: Touch throw animation, that happens when you *release* your finger after swiping ) - popup is opened , in which case all text input below in the z-order are proxied to bitmaps Another rather radical approach, which has been suggested by some ( DarkStone, Flexicious), would be to always display a StageText as a proxy bitmap when it's visible, and to show the StageText only when typing text via the soft keyboard. It's hard for me to believe that the Adobe SDK team went into all the pain of implementing the bitmap proxying, and the complex popup depth calculations (cf. StyleableStageText 3000+ lines of code) and didn't think about such a simple approach. So there must be something else! Some ideas come to mind: - memory concerns: maintaining bitmap proxies for all visible text inputs (and text areas), especially on high resolution displays, can be very costly. - time: maybe Flex was stopped at Adobe before this approach could be implemented, and TI was left in an intermediate state... Or maybe, they didn't see the scrolling issue... nobody is perfect. Does someone know ? Maurice -Message d'origine- De : DarkStone [mailto:darkst...@163.com] Envoyé : mercredi 30 octobre 2013 08:26 À : dev@flex.apache.org Objet : Re:Re: Re:Air Stage Text Issue Hi Naveen, I haven't got time to implement it yet. But I figure it out a better solution: 1. Create a class named VisualStageText which extends SpriteVisualElement class and implements IEditableText interface. 2. In the VisualStageText class implementation, define a private variable stageText:StageText, use it to implement IEditableText yourself, and also define a private variable snapshot:Bitmap. 3. Listen for VisualStageText instance's Event.ACTIVATE, Event.DEACTIVATE, MouseEvent.ROLL_OVER, MouseEvent.ROLL_OUT and other interaction relative events to detect user interactions. 4. When the user is currently interacting with VisualStageText, you need to hide the snapshot and show the stageText: snapshot.parent ? removeChild(snapshot) : null; snapshot.bitmapData.dispose(); snapshot.bitmapData = null; stageText.stage = stage; stageText.viewPort = new Rectangle(...); 5. When the user is not interacting with VisualStageText, you need to take a snapshot of the stageText, then hide the stageText and display the snapshot: var bd:BitmapData = new BitmapData(stageText.viewPort.width, stageText.viewPort.height); stageText.drawViewPortToBitmapData(bd); snapshot.bitmapData = bd; stageText.stage = null; addChild(snapshot); Well this is it, this is the core concept of how to do a Flex version StageText, you can use the VisualStageText as a MXML tag, and bind it to the skinpart of the spark TextInput (or TextArea)'s textDisplay:IEditableText. I plan to implement my VisualStageText at the end of this year, but if you can't wait you can do it by yourself, good luck : ) DarkStone
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
[FlexJS] Better FB Integration
I just posted a new FlexJSOverlay.zip at FlexJSOverlay.zip at [1]. It contains most recent dependency management and strict output corrections from Erik, and also contains better FB integration. You will need to remove your old FlexJS launch configurations and import new ones to get the benefit of this change. The new launch configs pass a -fb flag to Falcon which then reads the FB project files to determine the main compilation unit and other options. Not all MXMLC options are currently supported, so feel free to add new ones or file bugs about other missing ones. The key benefit of this change is that you no longer have to click on the main mxml file before running the launch configurations. Falcon can now figure it out based on what project you've selected in the package explorer and/or what file you are editing. As always, feedback and contributions are welcome. -Alex [1] http://people.apache.org/~aharui/FlexJS/FlexJSOverlay.zip
Re: [FLEXJS] Overlays and SWC Refactoring
On 11/18/13 12:19 PM, Erik de Bruin e...@ixsoftware.nl wrote: I'm clear. Sounds awesome! Let me know when the ant script is done, I'll work it into a Jenkins job so we get a fresh overlay for each commit to either Falcon(Jx) or FlexJS. Another advantage, besides being always up to date, is that this way there will be a fixed URL pointing to the latest and greatest overlay. By the way, did you see my commit for the defaults for the command line arguments to FalconJx? Having those should make the launch files a bit lighter, not having to set these arguments and all. No, I missed that. How does it work? FalconJX is also picking up the -library-path and main mxml file from the FB config, but having a way to pick up the other options would be great too. One thing I see coming up is that if you have a big enough project to have your own SWCs, once you cross-compile that SWC to a folder of JS files, there is no automagic mapping of the library-path to the SWC to the folder of JS files for that SWC. Maybe we can guess the folder of JS files from certain library-path entries? -Alex
[FlexJS] Cannot start app
Hi, I'm building the ListsTests using the latest FalconJX and flexjs repository pull. I had to make a fix to org.apache.flex.html.staticControls.Image but once that was completed (and now pushed) I get the following two errors when I run ListsTests in the browser: Error: Undefined nameToPath for goog.events.EventTarget new ListsTests().start(); ReferenceError: ListsTests is not defined new ListsTests().start(); I'm not sure what could be out of sync. Peter Ent Adobe Systems
Re: [FLEXJS] Overlays and SWC Refactoring
By the way, did you see my commit for the defaults for the command line arguments to FalconJx? Having those should make the launch files a bit lighter, not having to set these arguments and all. No, I missed that. How does it work? FalconJX is also picking up the -library-path and main mxml file from the FB config, but having a way to pick up the other options would be great too. They are actually overrides of the defaults set in the Configuration class and it's super classes. Nothing special, nothing dynamic ;-) One thing I see coming up is that if you have a big enough project to have your own SWCs, once you cross-compile that SWC to a folder of JS files, there is no automagic mapping of the library-path to the SWC to the folder of JS files for that SWC. Maybe we can guess the folder of JS files from certain library-path entries? You mean: how does my main project (JS version) connect to the SWC (JS version, compiled previously/separately)? Not sure if that's possible at all, as I said in a previous thread. The GCC process ALL files together, calculating dependencies and renaming/inlining whatever it finds, from all over the files. Now, there are way to 'publish' the API of one project/SWC (export, externs) and tell another project about it, but I'm not sure we'll be able to that automagically... EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FLEXJS] Overlays and SWC Refactoring
On 11/18/13 1:33 PM, Erik de Bruin e...@ixsoftware.nl wrote: By the way, did you see my commit for the defaults for the command line arguments to FalconJx? Having those should make the launch files a bit lighter, not having to set these arguments and all. No, I missed that. How does it work? FalconJX is also picking up the -library-path and main mxml file from the FB config, but having a way to pick up the other options would be great too. They are actually overrides of the defaults set in the Configuration class and it's super classes. Nothing special, nothing dynamic ;-) OK, I'll have to look into it. I'm specifically interested in how the -js-lib entries get set. One thing I see coming up is that if you have a big enough project to have your own SWCs, once you cross-compile that SWC to a folder of JS files, there is no automagic mapping of the library-path to the SWC to the folder of JS files for that SWC. Maybe we can guess the folder of JS files from certain library-path entries? You mean: how does my main project (JS version) connect to the SWC (JS version, compiled previously/separately)? Not sure if that's possible at all, as I said in a previous thread. The GCC process ALL files together, calculating dependencies and renaming/inlining whatever it finds, from all over the files. Now, there are way to 'publish' the API of one project/SWC (export, externs) and tell another project about it, but I'm not sure we'll be able to that automagically... Yes, we will have to handle the equivalent of external libraries, but in this case I'm asking about other libraries that get linked/compiled-in at publish time. Consider this case: In a large app with multiple engineers, each one is assigned a SWC to work on. Everybody's FB workspace has each of the SWC projects and the one main app project. Things are broken up to reduce compile time: changes to one SWC generally don't affect the other SWCs. The main apps' compiler settings has a -library-path entry pointing to each SWC. The SWF compiler sucks all of the ABC code from those SWCs into the SWF. On the JS side, those SWC engineers can run COMPCJX and get a pile of JS files. When building the JS app, they should also get the benefits of not having to wait to cross-compile every file from every SWC. This works today if you add additional -js-lib arguments to point to the other piles of JS code. GCC then compiles everything into one minified file. So my question for this scenario was whether there would be a way to map -library-path entries to -js-lib entries. The folks setting up their projects have a place to put the -library-path settings (in the compiler options), but there isn't a place (other than the launch configs) to put additional -js-lib folders. Maybe the default output folder for the JS code can be guessed from the -library-path settings? -Alex
Re: [FlexJS] Cannot start app
Yeah, my bad. I was so focussed on getting the release code to work that I forgot to check the debug code. Fixed now. EdB On Mon, Nov 18, 2013 at 9:30 PM, Peter Ent p...@adobe.com wrote: Hi, I'm building the ListsTests using the latest FalconJX and flexjs repository pull. I had to make a fix to org.apache.flex.html.staticControls.Image but once that was completed (and now pushed) I get the following two errors when I run ListsTests in the browser: Error: Undefined nameToPath for goog.events.EventTarget new ListsTests().start(); ReferenceError: ListsTests is not defined new ListsTests().start(); I'm not sure what could be out of sync. Peter Ent Adobe Systems -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FLEXJS] Overlays and SWC Refactoring
They are actually overrides of the defaults set in the Configuration class and it's super classes. Nothing special, nothing dynamic ;-) OK, I'll have to look into it. I'm specifically interested in how the -js-lib entries get set. 'sdk-js-lib' is handled in JSGoogConfiguration. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: Mobile TextInput Implementation status
Just received results of Om testing on Android (Tested on Samsung Galaxy SIII
(Android 4.1.2) and Samsung Galaxy Tab 2 (Android 4.2.2)).
It's working fine.
Thanks you Om for the quick testing, that's really good news.
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 16:49
À : dev@flex.apache.org
Objet : Mobile TextInput Implementation status
Memory profiling of the new skins:
It's as expected: alloc memory = pixel width x pixel height x 4bytes per
pixel.
First figure is for iPad , second is for iPad retina.
- 25KB / 100 KB of bitmap memory allocated for a single line TI with default
size
- ~500KB / ~ 2 MB for a pages stuffed with text inputs / text Areas
- 3 MB / 12 MB for a full-page TA = in this case, it's better to use the old
skins.
The bitmap is allocated while the TI is added to the stage, and disposed when
it's removed from the stage
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 02:10
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
1) to help debug if something goes wrong on Android, you can set the following
mx_internal flag:
ScrollableStageText.debugProxyImage = true;
It will display the proxy bitmaps in magenta background.
2) proxy methods in ScrollableStageText has been abstracted on purpose to
DisplayObject instead of Bitmap.
This is so that one could override the class to use another proxy (eg.
StyleableTextField) which is less memory consuming than bitmaps.
In wich case, you will have to override:
createProxy
updateProxy
disposeProxy
3) StageTextSkinBase inner textDisplay creation method is externalized so that
it can be customized.
Example for ScrollableStageTextInputSkin:
override protected function createTextDisplay():IStyleableEditableText
{
return new ScrollableStageText(multiline);
}
That way, you can derive from existing skins, instead of monkey patching the
default skin, if you only need to change the internal editable text class.
Note also that displayText is now of type IStyleableEditableText, instead of
StyleableStageText, for the same purpose.
Regards,
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 01:49
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Run mustella tests:
Mobile/Components/TextInput
Mobile/components/TextArea
Mobile/StageText
All pass.
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 01:11
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Hi, I have committed and pushed tentative fix for
https://issues.apache.org/jira/browse/FLEX-33166
Tested on iPad 2 / 3.
Not tested on Android.
I couldn't run mustella mobile tests. For some reason, they are broken on my
machine ( says: Passes: 0 / Fails: 0).
The new skins are now the defaults for TextInput and TextArea on mobile:
TextInput skinClass = spark.skins.mobile.ScrollingStageTextInputSkin
TextArea skinClass = spark.skins.mobile.ScrollingStageTextAreaSkin
The old skins are still there, under the same name.
Please review and tests, and this is a sensitive change...
Your comments and feedback are welcome.
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : lundi 18 novembre 2013 00:08
À : dev@flex.apache.org
Objet : RE: Mobile TextInput Implementation status
Founds some bugs, so I won't commit until they are fixed...
Maurice
-Message d'origine-
De : Maurice Amsellem [mailto:maurice.amsel...@systar.com]
Envoyé : dimanche 17 novembre 2013 21:18 À : dev@flex.apache.org Objet : RE:
Mobile TextInput Implementation status
I can help out with Android testing.
Thanks
Should I wait for the nightly or are these fixes on a branch? Nightly would
be preferable so as to allow more people to test the fix.
I will push to the develop/ so that they be in the nightly
It would be better to keep the old one around with the same name. Folks might
have subclassed it to build their own implementations.
What about :
ScrollableStageText
ScrollableStageTextInputSkin
For the new classes ?
Maurice
-Message d'origine-
De : omup...@gmail.com [mailto:omup...@gmail.com] De la part de OmPrakash
Muppirala Envoyé : dimanche 17 novembre 2013 20:27 À : dev@flex.apache.org
Objet : Re: Mobile TextInput Implementation status
On Nov 17, 2013 10:56 AM, Maurice Amsellem maurice.amsel...@systar.com
wrote:
Hi,
Here is a brief status of the implementation of Mobile Text Input,
along
with some questions:
Implementation overview:
The change is mainly on the class StyleableStageText, which now takes
the
opposite approach than the previous one:
- display proxy image bitmap by default
- display
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
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
Re: git commit: [flex-sdk] [refs/heads/develop] - UPDATED - Tentative FIX of FLEX-33166 Mobile TextInput with native StageTextInput cannot be included in scrollable forms - updated mustella baseline b
Hi, I checked all the before and after bitmaps and found one issue. In the ActionBar_TitleDisplay_TextDecoration test, the underline on the text Default Style is incorrect on the after bitmap as it turns black where it crosses the descender of the y. Thanks, Justin
Re: Build failed in Jenkins: flex-sdk_mustella #544
I was (am) a little confused about the version numbering of the new FP
(I assumed 12, Justin indicated it might be 12.0), so our beams
crossed and we ended up with a combination of the possible values.
That didn't work out well ;-)
I've change 'my' part to 12.0 and now at least the builds are running.
We'll see if they complete...
EdB
On Tue, Nov 19, 2013 at 6:07 AM, flex.muste...@gmail.com wrote:
See http://localhost:8080/job/flex-sdk_mustella/544/
--
[...truncated 944 lines...]
automation_agent_bundles-clean:
automation_agent_bundles-clean:
automation_agent_bundles-clean:
automation_agent_bundles-clean:
automation_agent_bundles-clean:
automation_agent_bundles-clean:
clean:
bundles-clean:
clean:
clean:
clean:
clean:
clean:
clean:
clean:
bundles-clean:
[echo] IN bundles clean
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
tool_air_bundles-clean:
clean:
airsdk-clean:
clean:
check-tlf-home:
bundles-clean:
clean-external:
[echo] cleaning C:/jenkins_slave/workspace/download-flex-tlf
[echo] FLEX_HOME is http://localhost:8080/job/flex-sdk_mustella/ws/
clean:
clean:
bundles-clean:
pixelbender-clean:
assets-clean:
clean:
bundles-clean:
clean:
bundles-clean:
assets-clean:
clean:
bundles-clean:
clean:
bundles-clean:
clean:
clean:
clean:
bundles-clean:
pixelbender-clean:
clean:
clean:
clean:
clean:
clean:
bundles-clean:
clean:
bundles-clean:
clean:
clean:
bundles-clean:
clean:
bundles-clean:
clean:
bundles-clean:
clean:
bundles-clean:
clean:
bundles-clean:
clean:
clean:
clean:
[delete] Deleting directory
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/libs
local-fonts-snapshot:
[touch] Creating
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/localFonts.ser
[touch] Creating
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/macFonts.ser
[touch] Creating
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/winFonts.ser
thirdparty-downloads:
swfobject-check:
swfobject-download:
swfobject-fabridge-download:
osmf-check:
osmf-download:
ask-osmf:
download-osmf-swc:
[copy] Copying 1 file to
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/libs
blazeds-jar-check:
ask-blazeds:
get-blazeds-jar:
blazeds-jar:
font-jars-check:
ask-font:
get-font-jars:
font-jars:
clean-adobe-flex-sdk:
optional-downloads:
main:
[echo] Use thirdparty-clean or super-clean to remove these.
prepare:
playerglobal-setswfversion:
flex-config:
[copy] Copying 1 file to
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks
compile:
framework:
bundles-clean:
pixelbender-clean:
assets-clean:
clean:
assets-compile:
[mxmlc] Loading configuration file
C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml
[mxmlc]
C:\jenkins_slave\workspace\flex-sdk_mustella\frameworks\flex-config.xml(28):
Error: configuration variable 'swf-version' value contains unknown token
'playerglobal.swfversion'
[mxmlc]
[mxmlc]swf-version${playerglobal.swfversion}/swf-version
[mxmlc]
[mxmlc] Apache Flex Compiler (mxmlc)
[mxmlc] Version 4.12.0 build 0
[mxmlc] Copyright 2013 The Apache Software Foundation.
[mxmlc]
BUILD FAILED
http://localhost:8080/job/flex-sdk_mustella/ws/build.xml:416: The following
error occurred while executing this line:
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/build.xml:112:
The following error occurred while executing this line:
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/build.xml:384:
The following error occurred while executing this line:
http://localhost:8080/job/flex-sdk_mustella/ws/frameworks/projects/framework/build.xml:246:
mxmlc task failed.
Total time: 1 minute 22 seconds
Build step 'Invoke Ant' marked build as failure
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
