On 11/6/13 11:53 PM, Justin Mclean jus...@classsoftware.com wrote:
Hi,
And the only difference between this and voting.html is that we allow
committers to veto as well as PMC members?
There's one or two other minor differences, for example:
However, the basic rule is that only PMC members
Hi,
I uploaded a new FlexJSOverlay.zip to my people.a.o folder. You can
follow the instructions at [1] to try it out.
This version contains support for Interfaces on the JS side, thanks to
Erik de Bruin, and the beginnings of a DataGrid, thanks to Peter Ent. It
also contains an updated Falcon
Hi Seb,
I have set 'wmode' to 'window' in html wrapper. do i need to change that?
Thanks,
Krish
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/video-not-working-in-full-screen-mode-in-windows-8-IE-10-metro-browser-tp31903p31999.html
Sent from the Apache
Alex,
I tried the new FlexJSOverlay and I encountered a few issues.
First: the deploy.sh and setuplaunches.sh don't handle spaces in the
file paths and don't handle relative paths. I've put the fixed files
here:
http://people.apache.org/~erikdebruin/flexjs/
Second: the compiler.jar (Closure)
Hi,
All i know is that direct mode will force the stageVideo mod. i don't
know more about wmode window.
if its not related to 4.11 and stageVideo, i m sorry to say that i won't
be much more helpfull.
you'd better try to find help on http://stackoverflow.com which is more
suitable for such
Ok, I have pushed the 'JSHint - gjslint' commits.
The framework classes are now clean against this gjslint command:
gjslint --strict --disable 0100 -r ./
I've used the --disable command because the new interface handling
relies on a variable on the prototype that is initialised with a 'non
On 11/7/13 3:42 AM, Erik de Bruin e...@ixsoftware.nl wrote:
Alex,
I tried the new FlexJSOverlay and I encountered a few issues.
First: the deploy.sh and setuplaunches.sh don't handle spaces in the
file paths and don't handle relative paths. I've put the fixed files
here:
Thanks, Erik. I'll make sure I run those tools on the JS code before
checking stuff in.
--peter
On 11/7/13 9:05 AM, Erik de Bruin e...@ixsoftware.nl wrote:
Ok, I have pushed the 'JSHint - gjslint' commits.
The framework classes are now clean against this gjslint command:
gjslint --strict
was last built by MXMLC and not Falcon (or was built by Falcon without the
-compiler.mxml.children-as-data flag). Every once in a while, FB will
suddenly re-build the SWF when you launch it. Not sure why. Om says it
happens every time for him. For me, I just run the external tool again
Awesome, thanks.
Any chance you can find time to put this 'recipe' in the wiki?
What are some of the coding style differences you saw between files? Just
whitespace? Or more? Peter and I did run lint most of the time, but I
wasn't using --strict so maybe that's why things went off the rails.
JSHint is about checking much more than whitespace and JSDoc (which is
it doesn't check at all ;-) That is why we need both tools, IMHO.
I could write a whole lot about the tool and why it will certainly
save your behind in large projects (check out my latest commits for
examples), but the tool
On Nov 7, 2013 7:50 AM, Erik de Bruin e...@ixsoftware.nl wrote:
was last built by MXMLC and not Falcon (or was built by Falcon without
the
-compiler.mxml.children-as-data flag). Every once in a while, FB will
suddenly re-build the SWF when you launch it. Not sure why. Om says it
Here is the Wiki entry:
https://cwiki.apache.org/confluence/x/W5sTAg
EdB
On Thu, Nov 7, 2013 at 5:11 PM, Alex Harui aha...@adobe.com wrote:
Awesome, thanks.
Any chance you can find time to put this 'recipe' in the wiki?
What are some of the coding style differences you saw between files?
On 11/7/13 7:49 AM, Erik de Bruin e...@ixsoftware.nl wrote:
was last built by MXMLC and not Falcon (or was built by Falcon without
the
-compiler.mxml.children-as-data flag). Every once in a while, FB will
suddenly re-build the SWF when you launch it. Not sure why. Om says it
happens
Well, I figured that if we have structural parity between the two
frameworks, several things will happen:
- type checking becomes consistent: as soon as there is a different
inheritance/implementation chain on the JS side, things go
pear-shaped: how about 'myClass is Sprite'?
- the frameworks
Ok, I have this working... It turns out that if you import the
FlexJSUI project as a library and link to that in your test project,
it works as advertised.
Not too surprising: this is Alex's exact setup.
So, another clue and another TODO item ;-)
EdB
On Thu, Nov 7, 2013 at 5:20 PM, OmPrakash
On the parity issue: if we manage a proper introspection thing on the
JS side, we should - in case of parity - be able to set up an
automated way of checking both sides for completeness and sameness.
EdB
On Thu, Nov 7, 2013 at 5:56 PM, Erik de Bruin e...@ixsoftware.nl wrote:
Well, I figured
On Thu, Nov 7, 2013 at 8:56 AM, Erik de Bruin e...@ixsoftware.nl wrote:
Well, I figured that if we have structural parity between the two
frameworks, several things will happen:
- type checking becomes consistent: as soon as there is a different
inheritance/implementation chain on the JS
- the frameworks will become easier to develop and maintain: build it
on the AS side, and start the work on the JS side by copying the class
structure. Or better yet, run the AS through the compiler and start
with the JS output, that way you should be able to start with a
reasonable
I can certainly see that certain higher-level components might be able
to have the same structure and have the JS side generated by the compiler.
But it seems to me that at some point,you need your platform abstraction
layer and what happens underneath it will vary.
Are you really suggesting
On 11/7/13 10:27 AM, OmPrakash Muppirala bigosma...@gmail.com wrote:
On Thu, Nov 7, 2013 at 8:56 AM, Erik de Bruin e...@ixsoftware.nl wrote:
Well, I figured that if we have structural parity between the two
frameworks, several things will happen:
- type checking becomes consistent: as soon
On 11/7/13 9:22 AM, Erik de Bruin e...@ixsoftware.nl wrote:
Ok, I have this working... It turns out that if you import the
FlexJSUI project as a library and link to that in your test project,
it works as advertised.
Not too surprising: this is Alex's exact setup.
So, another clue and another
No worries, they just reboot the windows slave, must've been right in the
middle of this build ;-)
EdB
On Thursday, November 7, 2013, Apache Jenkins Server wrote:
See https://builds.apache.org/job/flex-falcon/197/changes
Changes:
[erik] Added another pathway for finding 'goog' files by
FWIW, I was thinking that this kind of check should be replaced by some
capability in the tool chain to verify a configuration, maybe by marking
some values as required. In production, you hopefully don't need these
kinds of checks. I've also floated the idea of debug-mode beads which
have more
Hi Alex,
Could you please confirm the proposed cause of the issue, so that I can fix it :
https://issues.apache.org/jira/browse/FLEX-33862
Maurice
Maurice Amsellem
SYSTAR RD - BusinessBridgeFX
Hi,
The loop certainly looks incorrect and would cause it to freeze so I would go
ahead and check that in (after testing of course).
for (var i:int = n - 1; n = 0; i--)
Thanks,
Justin
Yes, but there is another potential issue: findHighestModalForm does not seem
to look in the correct child list, whatever the creation mode (PARENT or
POPUP), at least that's what the debugger says.
This part is tricky...
I prefer to fix both issues at once, and I need Alex's help for the
I'm good with that, but what if the original implementation was
significantly faster on JS but not on AS? Would you then allow for a
different implementation?
On 11/7/13 11:27 AM, erikdebr...@apache.org erikdebr...@apache.org
wrote:
Updated Branches:
refs/heads/develop 4b17f61ce - 9fa2c6f9b
Yep, that loop doesn't look right. I wonder why no mustella tests failed?
On 11/7/13 2:47 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
Hi Alex,
Could you please confirm the proposed cause of the issue, so that I can
fix it :
https://issues.apache.org/jira/browse/FLEX-33862
Maurice
Alex, please can you look at the second part in the JIRA comments (childrenList
lookup), which is more tricky...
Maurice
-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : vendredi 8 novembre 2013 01:20
À : dev@flex.apache.org
Objet : Re: Flex 38862 (modal popup
findHighestModalPopUp appears to be walking through rawChildren so the
child lists shouldn't matter. I haven't debugged into the test case. Do
I need to do that or can you explain quickly what you are seeing?
On 11/7/13 4:22 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
Alex, please
Try the test with TitleWindow instead of Hgroup in the popup. There may
be an issue with Hgroup not being an IFocusManagerContainer.
On 11/7/13 4:27 PM, Alex Harui aha...@adobe.com wrote:
findHighestModalPopUp appears to be walking through rawChildren so the
child lists shouldn't matter. I
Sure.
If I use Alert as the popup, systemManager.rawChildren contains modalWindow,
and the loop stops.
However,
1) if you add the popup with PopupChildrenList.POPUP, it's added in
popupChildren, and the loop does not find it.
2) most strange, if I add to the popup the class thatis provided
Try the test with TitleWindow instead of Hgroup in the popup. There may be
an issue with Hgroup not being an IFocusManagerContainer.
That's what I did: tried with Alert.show. It works.
Thanks for the explanation ( HGroup is not IFocusManagerContainer)
I will dig in that direction
Maurice
On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui aha...@adobe.com wrote:
FWIW, I was thinking that this kind of check should be replaced by some
capability in the tool chain to verify a configuration, maybe by marking
some values as required. In production, you hopefully don't need these
kinds of
I don't think there is support for modal popups that aren't
IFocusManagerContainer.
On 11/7/13 4:35 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
Try the test with TitleWindow instead of Hgroup in the popup. There
may be an issue with Hgroup not being an IFocusManagerContainer.
On 11/7/13 4:35 PM, OmPrakash Muppirala bigosma...@gmail.com wrote:
On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui aha...@adobe.com wrote:
FWIW, I was thinking that this kind of check should be replaced by some
capability in the tool chain to verify a configuration, maybe by marking
some values
I understand.
I quickly looked at IFocusManagerContainer implementers.
There are Canvas and Box, but not Group. Is that normal ?
So maybe the workaround would to use Box instead of Group ?
-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : vendredi 8 novembre 2013
Is that normal?
Sorry , that 's French word. I mean : is that intended ?
Maurice
-Message d'origine-
De : Maurice Amsellem
Envoyé : vendredi 8 novembre 2013 01:43
À : dev@flex.apache.org
Objet : RE: Flex 38862 (modal popup not working)
I understand.
I quickly looked at
In Spark-land, I thought there was SkinnableContainer as well. Group is
supposed to stay lightweight for FXG.
On 11/7/13 4:43 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
I understand.
I quickly looked at IFocusManagerContainer implementers.
There are Canvas and Box, but not Group.
Makes sense.
-Message d'origine-
De : Alex Harui [mailto:aha...@adobe.com]
Envoyé : vendredi 8 novembre 2013 01:46
À : dev@flex.apache.org
Objet : Re: Flex 38862 (modal popup not working)
In Spark-land, I thought there was SkinnableContainer as well. Group is
supposed to stay
So, my conclusion is that using Hgroup is invalid but there's definitely
a bug to be fixed in that loop. Thanks for finding it. I still can't
believe we don't have a test to catch that.
-Alex
On 11/7/13 4:47 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
Makes sense.
-Message
On Thu, Nov 7, 2013 at 4:41 PM, Alex Harui aha...@adobe.com wrote:
On 11/7/13 4:35 PM, OmPrakash Muppirala bigosma...@gmail.com wrote:
On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui aha...@adobe.com wrote:
FWIW, I was thinking that this kind of check should be replaced by some
capability
Alex,
I made more tests with HBox and PopUpManagerChildList.POPUP and loop breaks at
modalWindow.
I understand better now: popupChildren is a subset of rawChildren, so looking
in rawChildren is enough.
So I will simply fix the loop variable and commit.
Is that correct ?
Maurice
Hi Team,
There have been many issues fixed for 4.12.
Is it intended to deliver a 4.11.1 soon ?
In which case, maybe we should create 4.11.1 version in JIRA, and use it in the
FixVersion, instead of 4.12?
WDYT ?
Maurice
Sounds right to me. Thanks.
On 11/7/13 4:56 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
Alex,
I made more tests with HBox and PopUpManagerChildList.POPUP and loop
breaks at modalWindow.
I understand better now: popupChildren is a subset of rawChildren, so
looking in rawChildren
On 11/7/13 4:54 PM, OmPrakash Muppirala bigosma...@gmail.com wrote:
On Thu, Nov 7, 2013 at 4:41 PM, Alex Harui aha...@adobe.com wrote:
On 11/7/13 4:35 PM, OmPrakash Muppirala bigosma...@gmail.com wrote:
On Thu, Nov 7, 2013 at 2:18 PM, Alex Harui aha...@adobe.com wrote:
FWIW, I was
What is in the fixed list that we need to get out so quickly (because
there is no workaround or is a serious regression)?
On 11/7/13 5:11 PM, Maurice Amsellem maurice.amsel...@systar.com wrote:
Hi Team,
There have been many issues fixed for 4.12.
Is it intended to deliver a 4.11.1 soon ?
In
From the ones I have worked on :
- FLEX-33813Flex Incorrectly Scaling Down Application on iPad
is the only one that has no workaround, and is a regression.
My question was also on the JIRA process: is it the way it should work to mark
issues as fixed for the next major version ?
How was
Hi,
- FLEX-33813 Flex Incorrectly Scaling Down Application on iPad
I think there was also an issue with the Flex config RSL numbers - easily fixed
but still a pain.
My question was also on the JIRA process: is it the way it should work to
mark issues as fixed for the next major version ?
At this point in the development of the framework, no. Premature
optimization and all that… I'd maybe mark it as a TODO.
Remember, there is a second compiler (Closure) in the tool chain
which takes care of most of the 'bloat' when it is creating release code.
All those interfaces and nested
On 11/7/13 7:04 PM, Erik de Bruin e...@ixsoftware.nl wrote:
At this point in the development of the framework, no. Premature
optimization and all thatŠ I'd maybe mark it as a TODO.
Why would that be premature optimization? I guess I'm now confused as to
where you want to put the abstraction
On 11/7/13 3:42 AM, Erik de Bruin e...@ixsoftware.nl wrote:
Alex,
I tried the new FlexJSOverlay and I encountered a few issues.
First: the deploy.sh and setuplaunches.sh don't handle spaces in the
file paths and don't handle relative paths. I've put the fixed files
here:
At this point in the development of the framework, no. Premature
optimization and all thatŠ I'd maybe mark it as a TODO.
Why would that be premature optimization? I guess I'm now confused as to
where you want to put the abstraction differences? Making all
Sprite/DisplayObject APIs available
54 matches
Mail list logo
