On Nov 25, 2014 6:26 PM, "Alex Harui" wrote:
>
>
>
> On 11/25/14, 6:06 PM, "OmPrakash Muppirala" wrote:
>
> >>
> >> I’ll bet the relativeTo in org.apache.flex.states.AddItems isn’t being
> >>set
> >> or handled properly. I’ve not done any testing of overlapping
elements.
> >> AddItems and its fr
On 11/25/14, 6:06 PM, "OmPrakash Muppirala" wrote:
>>
>> I’ll bet the relativeTo in org.apache.flex.states.AddItems isn’t being
>>set
>> or handled properly. I’ve not done any testing of overlapping elements.
>> AddItems and its friends SetProperty and SetEventHandler are just data
>> objects
On Nov 25, 2014 5:59 PM, "Alex Harui" wrote:
>
>
>
> On 11/25/14, 5:29 PM, "OmPrakash Muppirala" wrote:
>
> >The elements that appear lower in MXML need to appear higher in the
> >display
> >order. But introducing States seems to be messing up the order.
> >
> >Any idea what's happening here? W
On 11/25/14, 5:29 PM, "OmPrakash Muppirala" wrote:
>The elements that appear lower in MXML need to appear higher in the
>display
>order. But introducing States seems to be messing up the order.
>
>Any idea what's happening here? Which class(es) would I look to debug and
>fix this issue.
I’ll
Hi,
> Yes, I have asked the board for advice on how the project can have fewer
> lengthy discussions like this.
Thanks for that. IMO it may of been better to put that in your original email.
Perhaps next time think about involving the PMC and/or perhaps (depending on
content) CCing the emai
I'm part of the Azure Advisors group with direct access to Azure engineers.
I'm not familiar with the matter here but if there is anything I can try to
escalate or any help I can try to ask let me know.
On Nov 22, 2014 3:44 PM, "Christofer Dutz"
wrote:
> Hi,
>
>
> I'm currently packing my stuff,
I am traveling and do not have my computer with me but I'll look as soon as I
return.
Peter
> On Nov 25, 2014, at 5:38 PM, OmPrakash Muppirala wrote:
>
>> On Tue, Nov 25, 2014 at 2:19 PM, Alex Harui wrote:
>>
>>
>>
>>> On 11/25/14, 12:19 PM, "OmPrakash Muppirala" wrote:
>>>
>>> I can c
The elements that appear lower in MXML need to appear higher in the display
order. But introducing States seems to be messing up the order.
Here is my very simple skin:
This is how it looks: http://snag.gy/5Kx0Y.jpg
When I remove the includeIn attribute like this:
This
HI,
> Here is a commit email [1]. Below is the relevant part. It shows you
> changing “utilize” to “utilise”.
I changed serval things in that commit to make it the REAME more
understandable. My locale happens to be en_AU and so that word was corrected as
a side effect, it was not a deliberat
On 11/25/14, 1:07 PM, "Justin Mclean" wrote:
>Hi,
>
>> Alex obviously asked for advice on how to handle this. That’s a
>>perfectly valid thing to do.
>
>Which is fine, but let Alex answer. I think it's a valid question, as
>part of the Apache Way is openness. [1]
Yes, I have asked the board fo
On 11/25/14, 1:34 PM, "Justin Mclean" wrote:
>
>Actually what started this off is that Alex submitted a commit that
>changed something into US English and the previous spelling errors being
>a blocker to releases discussion.
Here is a commit email [1]. Below is the relevant part. It shows you
HI,
+1 Binding
- Signatures and hashes good
- NOTICE and LICENSE correct
- all source files have correct headers
- no unexpected binaries in release
- can compile from source
- checked Squiggly and 3rd party examples
Thanks,
Justin
On 11/25/14, 2:41 PM, "OmPrakash Muppirala" wrote:
>
>> I’m not sure if the hooks from FB are that low level. I can
>> try it myself if you want. Did you make sure that FlexJS and not
>>regular
>> Flex is compiling the code? Is it using a FlexJS flex-config? Also,
>>did
>> you restart FB?
>
> >Yes, I have been using FB all this while with no issues. But it looks
> >like FlexJSUI's mx.states has started deviating from the Flex SDK version.
> >Which is manifesting as a problem now.
>
> In theory it should be ok to deviate from the API surface of the current
> Flex SDK.
Of course,
On Tue, Nov 25, 2014 at 2:19 PM, Alex Harui wrote:
>
>
> On 11/25/14, 12:19 PM, "OmPrakash Muppirala" wrote:
>
> >I can confirm that the release version of the FlexJS (0.0.2) can compile
> >this project fine and run without errors. Whereas the latest code from
> >develop branch, has the runtime
On 11/25/14, 11:02 AM, "OmPrakash Muppirala" wrote:
>On Nov 25, 2014 10:56 AM, "Alex Harui" wrote:
>>
>>
>>
>> On 11/25/14, 10:45 AM, "OmPrakash Muppirala"
>>wrote:
>>
>> >The mx.states package in FlexJSUI is causing a collision with the Flex
>> >SDK's mx.states package. Is there a reason wh
On 11/25/14, 12:19 PM, "OmPrakash Muppirala" wrote:
>I can confirm that the release version of the FlexJS (0.0.2) can compile
>this project fine and run without errors. Whereas the latest code from
>develop branch, has the runtime error below:
>
>(I din't realize that I had sent this message w
Hi Justin,
I just responded off list.
Thanks,
Harbs
On Nov 25, 2014, at 11:34 PM, Justin Mclean wrote:
> Hi,
>
>> It’s an antagonistic question
>
> Zero antagonism was meant or even implied. I know email tone can be hard to
> decipher sometimes, but please don't assume ill intent when none
Hi,
> It’s an antagonistic question
Zero antagonism was meant or even implied. I know email tone can be hard to
decipher sometimes, but please don't assume ill intent when none exists. Also
please try to be a little more courteous and respectful on this public email
list.
> He wants to dis
On Nov 25, 2014, at 11:07 PM, Justin Mclean wrote:
> I think it's a valid question
No it’s not. It’s an antagonistic question and has nothing to do with the pros
and cons of the discussion.
Let’s say Alex made that up. Who cares? He wants to discuss how to handle
localization/languages/whatev
Hi,
> Alex obviously asked for advice on how to handle this. That’s a perfectly
> valid thing to do.
Which is fine, but let Alex answer. I think it's a valid question, as part of
the Apache Way is openness. [1]
Thanks,
Justin
1. http://theapacheway.com/openness
Justin,
Please give it a break.
Alex obviously asked for advice on how to handle this. That’s a perfectly valid
thing to do.
On Nov 25, 2014, at 10:18 PM, Justin Mclean wrote:
>> The board member who has been trying to follow the project recommends we
>> put the issue of US vs Int’l English t
Hi,
> So how about adding this:
>
> “Good-faith efforts at modifying text by non-native speakers generally
> should not be vetoed. Instead, native speakers are encouraged to thank
> them and simply make corrections.”
I'm not sure why you are singling out non native speakers here, any effort to
I can confirm that the release version of the FlexJS (0.0.2) can compile
this project fine and run without errors. Whereas the latest code from
develop branch, has the runtime error below:
(I din't realize that I had sent this message went to Alex alone)
-- Forwarded message --
F
Hi,
> The board member who has been trying to follow the project recommends we
> put the issue of US vs Int’l English to a vote.
Where was this recommended? If it didn't happen on the mailing list it didn't
happen.
> Apparently, the HTTP project did so in the past (and decided on US English).
Hi Alex,
exactly ... you need credentials printed in plain text in order to be able to
deploy to apaches maven repo. If we were to have this done from our machine,
someone of ous would have to donate his credentials to our build machine
readable for the others. I would not want to do this and I
>>- This is a solution looking for a problem; a waste of everyone's time.
>
> Well, it is the board member’s recommendation. I actually hope to use the
> proposal as a way to invite folks to contribute translated versions.
Board members don't make project policy. But that aside, I wasn't
talking
On Nov 25, 2014 10:56 AM, "Alex Harui" wrote:
>
>
>
> On 11/25/14, 10:45 AM, "OmPrakash Muppirala" wrote:
>
> >The mx.states package in FlexJSUI is causing a collision with the Flex
> >SDK's mx.states package. Is there a reason why they have the same
package
> >names.
>
> I was previously unable
On 11/25/14, 10:45 AM, "OmPrakash Muppirala" wrote:
>The mx.states package in FlexJSUI is causing a collision with the Flex
>SDK's mx.states package. Is there a reason why they have the same package
>names.
I was previously unable to get FB to recognize a FlexJS SDK as a Flex SDK
(needed to g
>
> I moved FlexJS up in the dependency list in the build path.
I meant: I moved FlexJSUI up in the dependency list in the build path.
On Tue, Nov 25, 2014 at 10:45 AM, OmPrakash Muppirala
wrote:
> The mx.states package in FlexJSUI is causing a collision with the Flex
> SDK's mx.states package
The mx.states package in FlexJSUI is causing a collision with the Flex
SDK's mx.states package. Is there a reason why they have the same package
names.
Why not org.apache.flex.states instead?
Is there a way to tell FB to use FlexJSUI's mx.states.* instead of the Flex
SDK's? Here is what I tried
On 11/25/14, 12:37 AM, "Erik de Bruin" wrote:
>My vote would be a -0 right now, strongly leaning towards a veto - on
>principle.
>
>I object on (at least) 3 points:
>
>- This is a solution looking for a problem; a waste of everyone's time.
Well, it is the board member’s recommendation. I actu
Regardless of the rest of the standardization, I think we should still allow
translation of user docs, website, wiki and GUI tool. Meaning not enforcing a
standard, but allowing better support for alternate languages if someone
desires to put forth the effort of translating.
-Mark
Hi,
Just a friendly notice that I will be cutting the release branch for
Flex SDK v. 4.14 on Dec. 12th at 9 AM (UTC: 2014-12-12 09:00).
This means that any contributions - features, bug fixes, documentation
changes/additions etc. - that have not been checked into the 'develop'
branch at that time
Same vote intention than Erik for the same reasons.
Frédéric THOMAS
> From: e...@ixsoftware.nl
> Date: Tue, 25 Nov 2014 09:37:10 +0100
> Subject: Re: [DISCUSS] Localization Proposal (was re: International English)
> To: dev@flex.apache.org
>
> My vote would be a -0 right now, strongly leaning to
I did not understand Alex’s suggestion as changing the status quo.
The default language is currently US English. UI-facing components are already
localized. That would all stay the same.
The only suggestion would be to make a (reasonable) effort to use neutral words
when possible and possibly o
Hi Erik,
I know that we have now only one failing test class (FloatTest) in tables
branch. Once Harbs fix it I'm ok from my point of view to merge everything
into develop branch.
Piotr
-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context:
http://apache-flex-developm
My vote would be a -0 right now, strongly leaning towards a veto - on principle.
I object on (at least) 3 points:
- This is a solution looking for a problem; a waste of everyone's time.
- Enforced language rules will raise the bar for entry, especially for
non-native speakers. It's hard enough m
We can probably merge it into develop.
I’m about ready to use it in production, although I do know of one regressive
TLF bug that I need to look into. Selecting all text and pressing enter causes
the TextFlow to get in an unstable state. (I think — unless it’s a bug in my
own app)
I have not h
Harbs, Piotr, all,
I have put the 'tables' branch of TLF against my own apps, and have
not found any (obvious) issue with backwards compatibility. Everything
looked and behaved just fine.
I think we are now at a point where we merge 'tables' into 'develop'.
You continue work on the tests in 'deve
40 matches
Mail list logo
