Roundtable on changing perceptions. It's hard to find anything in the media
that isn't old or advising developers to run.
Enterprise development roadmap. I would like to tell my developers to start
moving away from mx:hasNoFuture components.
--
View this message in context:
http://apache-flex-
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 runn
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
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 2
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
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.amse
>>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
--
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 wrote:
> Hi,
>
> I'm building the ListsTests using the latest FalconJX and flexjs repository
> pull.
>
> I had to make a fix to
On 11/18/13 1:33 PM, "Erik de Bruin" 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? Falco
>>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
OK, I've moved the as code into a subfolder. The ant build for
FlexJSUI.swc is probably broken, but I'll be working on it and a
uber-script now. But you should be able to modify AS classes after
pulling and any further work I do should not result in a conflict.
-Alex
On 11/18/13 12:30 PM, "Alex
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
On 11/18/13 12:19 PM, "Erik de Bruin" 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 the
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 gre
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 o
Right now, you can play with FlexJS by getting a FlexJSOverlay.zip and
following a set of instructions. The reason it is called FlexJSOVERLAY is
because it overlays a hacked up copy of framework.swc on top of the
framework.swc in a working Flex SDK.
Framework.swc is used by MXMLC when it compiles
On 11/18/13 11:19 AM, "Maurice Amsellem"
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 matte
>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.
I made some m
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
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"
wrote:
>>I can try to ask the engineer who worked on it to see if he remembers
>
>Hi Alex,
On 11/18/13 9:38 AM, "Maurice Amsellem"
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
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é
>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
On 11/18/13 8:25 AM, "Maurice Amsellem"
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
>be
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
> 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 teste
>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 p
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 the
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 w
>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...@a
Hi people,
only to notify that the site from peter is again down.
The information there is price less, this will be solved or is for sure that
the famous blog will be down?
Kind regards,Miguel
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:
[...]
(StyleableStageText includes StageText , but it do
Probably you misread the following:
"The Actionscript Compiler 2.0 has been incorporated into the AIR SDK
4.0 (named “AIR SDK 4.0 & Compiler”) and retired as a separate download
from Adobe Labs on March 14, 2013".
Here's nothing new to us. AIR SDK is still published in 2 variants: with
ASC 2.
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
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
35 matches
Mail list logo
