[FalconJx] Compiling i18n properties / ResourceBundles
Besides ActionScript and MXML, there is a third source file format for
which mxmlc can produce code: properties files.
Thus, for FalconJx, like for MXML, we have to decide which way to go: either
1. let Falcon generate the temporary ActionScript class and compile that
to JavaScript, or
2. produce JavaScript code or maybe even data (JSON?) directly from the
properties file.
But first, let me summarize how mxmlc handle properties files for i18n.
Most of this is from the documentation on
ResourceBundleshttp://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7fcf.html,
some facts I reverse-engineered by playing with Flex 4.6. As I don't really
have practical experience with Flex and ResourceBundles, can someone please
confirm or correct what I found out so far?
As I understand, mxmlc takes a Foo.properties file from source path
locale/{locale} (or any other pattern specified as part of the source path)
and generates a class {locale}$Foo_properties for each given locale. Each
of these classes is a subclass of mx.resources.ResourceBundle and calls
super({locale}, Foo). It overrides getContent() and returns an Object
literal defining all the key/value pairs from
locale/{locale}/Foo.properties.
The ResourceBundle superclass registers with the singleton
mx.resources.ResourceManager (interface IResourceManager implemented by
ResourceManagerImpl), which, given some key, returns the right value
according to its current localeChain.
The annotation [ResourceBundle(Foo)] at some class Bar establishes
dependencies of Bar on all ResourceBundle classes {locale}$Foo in the
current locale chain. That means when mxmlc is run with locale=en_US,de_DE,
both en_US$Foo and de_DE$Foo will be linked into the generated SWF, and Bar
will instantiate both ...$Foo classes, so that they register with the
ResourceManager and Bar can access the key/value pairs they define through
ResourceManager.getInstance().getString(Foo, text) or, in MXML,
@Resource(bundle=Foo, key=text), where the latter automatically adds
the [ResourceBundle(Foo)] annotation to the class generated from the MXML
file.
You have two ways of deploying different locales: either compile all
different locales into one SWF, or produce a separate SWF for each locale
and load the one(s) needed on demand.
What I did not figure out is whether it is possible / makes sense to put
such generated ResourceBundle subclasses into a package. I put a properties
files into a locale/{locale} subdirectory, say
locale/en_US/acme/Foo.properties, and as expected, mxmlc (I used Flex 4.6)
generated a class acme.en_US$Foo_properties. However, the class still
registered with the ResourceManager under the name Foo, not acme.Foo,
so my attempt to avoid name clashes (after all, that's what packages are
for) was rendered void.
Is there any way to put properties in a package, or is it simply not
possible with mxmlc? If the latter, should we change this behavior for
Apache Flex / Falcon?
For FalconJx, the question is whether we want to
1. accurately mimic how mxmlc handles properties files and generate
ResourceBundle subclasses that register with the ResourceManager, or
whether we'd rather
2. find a more straight-forward, efficient way to get the key/values for
the requested locales to the client and feed them directly into the
ResourceManager.
For the first approach, does Falcon already generate the temporary
ResourceBundle subclass? Then we could just fetch it and compile it to
JavaScript as usual. I'm sure the [ResourceBundle(...)] annotation can be
implemented in Falcon to add the required dependencies on the
ResourceBundle subclasses.
For the second approach, we'd generate JSON files from properties files and
the [ResourceBundle(...)] annotation would have to take care of loading
these into the ResourceManager directly. Following the AMD approach I
proposed, we could take advantage of the RequireJS i18n
pluginhttp://requirejs.org/docs/api.html#i18n.
However, it seems to me that Flex has a different fall-back / default
semantics than RequireJS---we'll have to investigate on this.
What do you think would be the better approach? Or should we try both?
In both cases, we have to think about which kinds of optimized deployment
we want to support. For applications that come in many different locales,
linking all locales into one big JS would be quite a waste, so it should be
possible to create locale bundles that are loaded depending on the user
locale.
Greetings,
-Frank- J8)
Re: interested in contributing to Apache Flex
Hey, Thanks for such a concerned reply. Can you forward me that mail thread from Michael since I added myself on the list yesterday itself, so i don't have it. On Mon, Jan 21, 2013 at 2:23 AM, Kevin George kevin-geo...@hotmail.comwrote: I too have added myself on this list 2 days back and watching every mail trying to get an idea of what is happening. The recent mail thread from Michael explained a lot on the FalconJX project. Hoping to jump onto the bandwagon soon. P.S I come with a 3 year experience in the Flex 3.x. Recently moved to 4.x Sent from Windows 8 Mail From: Prashant Pandey Sent: 21 January 2013 01:33 To: dev@flex.apache.org Subject: interested in contributing to Apache Flex Hi, I am an undergrad student having good Java and Algorithmic skills. I wish to contribute to an open source organization and the project Apache Flex appeals to me very much. Henceforth I am keenly interested in contributing something productive and fruitful to this project. Since I am new to open source, can someone help me out, how to start with the project so that I can do something beneficial. Thanks and Regards Prashant Pandey
Re: Apache Flex download statistics
On Fri, Jan 18, 2013 at 9:00 AM, Om bigosma...@gmail.com wrote: ...Who should I ask if this it is okay for us to embed GA scripts on the site?... Using Google Analytics is ok if the PMC agrees to do that but the site needs to make this explicit, stats need IMO to be shared with the PMC (not sure if google terms allow the project to make them public, I remember seeing discussions about that) and the analytics account credentials must be shared with the PMC (for example under https://svn.apache.org/repos/private/pmc/ ) http://jackrabbit.apache.org/privacy-policy.html is a good example of making analytics explicit on the project website. -Bertrand
[FlexJS] moved js library in SVN
Alex, A heads up: I've moved the FlexJS js framework into a new subdirectory of 'frameworks/js': 'FlexJS'. I needed to do this to make room for my new VanillaSDK framework (more on that later). Sorry to give you extra work adapting the paths in your projects and on the Wiki. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: interested in contributing to Apache Flex
Hi, Can you forward me that mail thread from Michael since I added myself on the list yesterday itself, so i don't have it. All email is archived in several archives. You should be able to find it here. http://markmail.org/search/+list:org.apache.incubator.flex-dev http://mail-archives.apache.org/mod_mbox/incubator-flex-dev Thanks, Justin
Re: interested in contributing to Apache Flex
On Mon, Jan 21, 2013 at 11:48 AM, Justin Mclean jus...@classsoftware.com wrote: ...All email is archived in several archives. You should be able to find it here. http://markmail.org/search/+list:org.apache.incubator.flex-dev... Note that this is conveniently available at http://flex.markmail.org/ -Bertrand
Stage3D accelerated Flex components
I've done some experiments with Stage3D accelerated Flex components, derived from MadComponents classes. http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/ It is my intention to port MadComponents to ASnext. I propose that these ported MadComponents/MC3D classes might form the basis of a new Flex mobile framework that utilises hardware GPU rendering. I'm aware that Thibault Imbert has proposed that a new Flex framework should be based on Starling and Feathers. But I believe that the MC3D approach is better suited to the next Flex mobile framework. MadComponents is a fully fledged framework, not just a UI framework. It allows for versatile styling of components (without having to design texture skins), server communication, and memory management. However, until we know more about ASnext, which framework approach to choose is mostly speculation. So I'd like the members of this group to read my blog post, and let me know what they think.
Re: Stage3D accelerated Flex components
Interesting article and I have read quite a bit of what you have done in the past. I don't know if this is a translation thing but; While I am willing to advise the Open Flex developers, and participate in discussions (time and other-commitments permitting), I am not willing to write the new Flex framework for them. I would expect the Open Flex group to put in the development work for this ? not me. the above paragraph made me feel like I wanted to hit the back button when I got to it. BTW, I'm not married to the Flex legacy either and I am in this project because of the ActionScript language. Yes, I have read your thoughts about that as well. If your idea of a component framework was embraced by an abstract open source community, I don't think anybody would expect you to do anything, it seems like you are offering consulting services correct? If you were honest about adding advice it would be right on this list like we all do. Mike Quoting Daniel Freeman madcompone...@gmail.com: I've done some experiments with Stage3D accelerated Flex components, derived from MadComponents classes. http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/ It is my intention to port MadComponents to ASnext. I propose that these ported MadComponents/MC3D classes might form the basis of a new Flex mobile framework that utilises hardware GPU rendering. I'm aware that Thibault Imbert has proposed that a new Flex framework should be based on Starling and Feathers. But I believe that the MC3D approach is better suited to the next Flex mobile framework. MadComponents is a fully fledged framework, not just a UI framework. It allows for versatile styling of components (without having to design texture skins), server communication, and memory management. However, until we know more about ASnext, which framework approach to choose is mostly speculation. So I'd like the members of this group to read my blog post, and let me know what they think. -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: Stage3D accelerated Flex components
I think it's apparent that you've done a lot of work here, and your approach has merit. Like Mike says, keeping an open discussion here, would be a good thing. Personally, I have not done much mobile work, but that will likely change in the near future. So until then I don't have much to comment on... On Jan 21, 2013, at 1:30 PM, Daniel Freeman wrote: I've done some experiments with Stage3D accelerated Flex components, derived from MadComponents classes. http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/ It is my intention to port MadComponents to ASnext. I propose that these ported MadComponents/MC3D classes might form the basis of a new Flex mobile framework that utilises hardware GPU rendering. I'm aware that Thibault Imbert has proposed that a new Flex framework should be based on Starling and Feathers. But I believe that the MC3D approach is better suited to the next Flex mobile framework. MadComponents is a fully fledged framework, not just a UI framework. It allows for versatile styling of components (without having to design texture skins), server communication, and memory management. However, until we know more about ASnext, which framework approach to choose is mostly speculation. So I'd like the members of this group to read my blog post, and let me know what they think.
Re: Stage3D accelerated Flex components
I would expect the Open Flex group to put in the development work for this ? not me Let me clarify what I mean. It is my intention to port MadComponents/MC3D over to ASnext. This is quite an undertaking. Combined with the effort that I've already put into the framework, and the new GPU-enabled effects. To turn this into a Flex framework - all you'd need to do is write Flex wrappers. Along the lines of the examples that I demoed in 2011, but writing them in such a way as to maintain the familiar conventions of Flex in mxml. Also, tweaks to the MD3D classes to allow them to work within Flex. But most of the hard work will be already done. So this is a little more than free consultancy (although that in itself would have been generous).
Re: [FalconJx] MXML implementation notes
Alex,
Responding inline would be to much of a mess.
Basically half of my post was about the data spec. So you asking if I
am looking for the data spec, my answer would be yes.
I'm just trying to write a list of things I need to generate.
To reiterate, I understand we are generating data structures, descriptors.
We have to generate
- wrappers for event handlers
- conceptually seems pretty straightforward
- deal with inner classes
- What do you mean inner classes, the Component tag?
- script blocks
- these are IASNodes that are directly on the tree, this should not
be hard, the way the current block emitter is setup with visit methods
can push this stuff out right in the TypeScope
- CSS
- No idea right now, needs more thought
- binding syntax
- Since I have good ActionScript emitting, I can't see how the {}
syntax in an attribute would be hard to generate. I may be
underthinking but I really think that is doable soon.
I will post any more direct questions I may have when I encounter them.
Mike
Quoting Alex Harui aha...@adobe.com:
On 1/20/13 1:50 PM, Michael Schmalle apa...@teotigraphix.com wrote:
Hi,
Alex this one is aimed at you. I have been studying what you have done
for the whole day today and managed by copying about 1000 various
lines of code to my prototype MXML emitter got your Fragment lists to
be populated by my traversal.
Now the question is, can you in about 5-6 paragraphs give me a nice
detailed approach of yours with what is needed.
For example, I see;
- The main application mxml file, this looks as though it's getting
translated pretty vanilla.
Not sure what you mean by that. For sure, I might have missed generating
some pattern the goog way. But it seemed like most of the goog-ness is in
the class and method signatures not in the function body, but I might have
missed something there.
- you are renaming with the dummy post fix, why?
I am? I didn't think so. Also remember, lots of this code is not mine so
it might be doing something I'm not aware of.
- in the constructor you are just using the InstanceNode values (I
know this is all being done behind the scenes, I get how the
directives work now and are processed recursively)
The constructor stuff could need work. I didn't do too much in the way the
constructor is reduced and mostly changed the way it gets emitted.
- The MyInitialView is sketchy, is uiDescriptors being created by you
or is that property created by the MXMLClassDirective?
MXMLClassDirective is the old-school code-gen. I have altered code paths in
many of the methods by adding the mxml.children-as-data flag. That causes
MXMLClassDirective to spit out the MXMLDescriptors and MXMLProperties arrays
that contain a description of the MXML tags. We are not going to use the
old code-gen: we will require this flag be set. But the AS code can consume
this kind of output, and I have a similar interpreter for the old SDK code.
JSMXMLClassDirective then just tries to transcode this stuff into JS.
- Same with he event handlers, I see that is being take care of by the
process method.
I really think if you can give me as much information of what you are
doing and need, I could have FalconJx producing the MXML sooner than
later. As I said I already have it spinning, just need to know exactly
what you need at the moment.
I'm not 100% sure what you are looking for, the philosophy I have is that
MXML should generate as little code as possible. It should just generate
data where it can, so the AS/JS framework can generate the right widgets at
runtime. One thing you can't do is AS is generate new methods on the fly,
so the only code I think we have to generate is event handlers and complex
databinding expressions. Everthing else becomes data. Are you looking for
a spec on the data format?
Also, this is where the framework will work out nice since when I need
to emit ActionScript for the MXML, I will pass it the current emitter
and send it through the ASBlockWalker.
This was a rough spot for me in the FalconJS code. You can be traversing
nicely through MXML nodes then hit AS nodes which in the FalconJS code start
calling the reducer and setting up the SWF constructs. Hopefully that
transition will be smoother for you.
I will also be honest and say, MXML is an ugly duckling compared to
surfing the AS AST, so when I say I can get your code working sooner
than later, I really mean I can get exactly what you have, to prove we
have all the right tools to put effort into the FalconJx version
because it will produce everything we need.
I'm not sure what you mean by that, the tree walk seems pretty
straightforward to me, but yeah, what you emit is trickier. I think I've
made it harder by trying to build out that data structure, but we need data
and not code in order to allow it to be interpreted differently in AS vs JS.
Other than that, I think it is standard pain for MXML. We have to generate
wrappers for event
Re: Stage3D accelerated Flex components
On Mon, Jan 21, 2013 at 10:31 PM, Avi Kessner akess...@gmail.com wrote: Conceptually, I don't understand why you would want to have more than just a UI framework, if your goal is to make use of the GPU. The fewer dependencies the better. @Avi, I see memory management, and server communication as important aspects of MadComponents. Not dependencies. How do you mean? @Michael, I don't see anything wrong with drawing a line as to how much more my time I can dedicate to this project. Or asking for commitment and work from the Open Flex developers. I just didn't want everyone to run away with the idea that I was going to do ALL the work (in my experience, people usually expect that). MadComponents/MC3D are free and open source. http://opensource.org/licenses/mit-license.php I wouldn't be adverse to maintaining it under Apache, as I think that getting more developers involved in the core MadComponents/MC3D classes could be positive. But it's a little early to talk about that now. I was thinking we should maintain the code separation between the Flex wrappers, and the core MadComponents/MC3D classes.
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Frank, Let me be direct, do you want to start working on AMD output? IMO you should definitely finish up the Wiki stuff so it clear what needs to be done with AMD output. Your MXML interpretation is the way I would see it as well. It's crystallized until invoked. That is what I meant by intention, it's not a true class template until it has been deserialized by the compiler. Mike Quoting Frank Wienberg fr...@jangaroo.net: On Sun, Jan 20, 2013 at 11:28 PM, Michael Schmalle apa...@teotigraphix.comwrote: I think what my plan is, is to tell you I'm not going to ignore you, I'm focused on MXML just so I can get it into the flow. After I get it committed I will try and see what is going on with the code you wrote. Totally fine. While you are busy with MXML, I could spend my time getting started with FalconJx and/or finishing the AS-JS Wiki page. I am also pretty sure there are some others out there that may want to help out on something but the documentation on what we are doing is a but technical. Alex brought up a good point about the MXML and needing it soon, if I don't do it right now before we get head long into the finite part of the compiler, I'm going to end up resenting working on it. :) Actually, working on it today really gives me a sense of anticipation because MXML is one thing we have in our favor that could end up being something that can set this project apart and really allow for some interesting types of innovation. Who knows, we will keep that for the future. Yes, MXML is something all languages-that-compile-to-JavaScript competitors (TypeScript, Dart, Haxe, ...) currently lack! Along those lines, for now I don't see MXML as really a class one to one. It's more of and intentional declaration of intent. Does that phrase make sense to you? I guess you're talking about what I'd call an object descriptor, like ECMAScript 5 has the concept of property descriptor that is not the actual property, but a descriptor to create a property. A class is something quite similar to an object descriptor (because you have to instantiate it to get an actual object). If I understand your point correctly, MXML cannot create arbitrary classes (well, I guess it can through mx:Script elements, but that's kind of dirty), but limits itself to the declarative part, i.e. defining properties and instantiating and wiring other objects through their properties. Right? Another way to view MXML is as an object serialization format. Although MXML is not used to store objects, serialization also focuses on object properties, not their methods / behavior. Behavior is added (through classes) on deserialization. -Frank- J8) -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: Stage3D accelerated Flex components
@Mike, I've updated my wording slightly. But it's getting late (Brisbane time), and I'll see how things look in the morning. I don't apologies for carefully qualifying my expected contributions, and my expectations of other people's contribution. While I've changed the wording and dressed it up a little differently - I'm still not willing to write all of this for you - with no contribution from this group. As MadComponents has became popular - there's been increasing expectation on me to maintain, enhance, and support developers using it. While I've tried to share the burden with other developers - I've still had to contribute more time to this project than I've been comfortable with.
Re: [FlexJS] moved js library in SVN
Mike, I looked through your committed code and see and AIR app there. hmmm.. Putting the horse before the cart are we? No, I'm not (if I understand the idiom correctly). I'm working on tying the work we did on FJx to the work I did on the JS publisher earlier. This should help Alex get a better sense of what's possible with FJx and make his case to the powers that be. I already have the entire framework on the AS side completed... it's the Flex SDK :-P I'm just throwing together a quick and dirty POC on the JS framework side. I'm now playing with that AIR app you mentioned to put an AS project through FJx and create a working HTML project. This will take me the better part of today, but I hope to be able to commit something moderately useful before too long. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle apa...@teotigraphix.comwrote: Frank, Let me be direct, do you want to start working on AMD output? Not necessarily right now. Still seems like a steep learning curve for me. IMO you should definitely finish up the Wiki stuff so it clear what needs to be done with AMD output. I was straightly asking what helps you most, so if you say let's get the specification finished first, I'll continue with that ASAP! Cheers -Frank- J8)
Re: [FlexJS] moved js library in SVN
HAHA, I love different cultures, this was actually a joke! The idiom is cart before the horse, I said horse before the cart which means you are getting everything prepared first before the engine. :) Which is how I would do it! Interested in what you have baked up with the current SDK, I think I can see what you might have in mind, I will be curious to see if my intuition is correct. BTW, I am working on MXML right now, wow MXML might prove to be a real powerful thing to have. Mike Quoting Erik de Bruin e...@ixsoftware.nl: Mike, I looked through your committed code and see and AIR app there. hmmm.. Putting the horse before the cart are we? No, I'm not (if I understand the idiom correctly). I'm working on tying the work we did on FJx to the work I did on the JS publisher earlier. This should help Alex get a better sense of what's possible with FJx and make his case to the powers that be. I already have the entire framework on the AS side completed... it's the Flex SDK :-P I'm just throwing together a quick and dirty POC on the JS framework side. I'm now playing with that AIR app you mentioned to put an AS project through FJx and create a working HTML project. This will take me the better part of today, but I hope to be able to commit something moderately useful before too long. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Great! Here is my thought Frank, I see no reason for you to even have to write the AMD part. It dosn't make sense from a standpoint of time, when I get some other things out of the way, if I have a good spec it would take me less than a week with tests. This will allow you to focus on other things. BTW I wanted to ask, how does this now from your view fit into the tool chain IE IDEs, how do you work. Use IntelliJ for example. I'm curious because I have a WebAudio project I am going to be starting and I want to know how I would hook the compiler up to it's build system. Ideas? Mike Quoting Frank Wienberg fr...@jangaroo.net: On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle apa...@teotigraphix.comwrote: Frank, Let me be direct, do you want to start working on AMD output? Not necessarily right now. Still seems like a steep learning curve for me. IMO you should definitely finish up the Wiki stuff so it clear what needs to be done with AMD output. I was straightly asking what helps you most, so if you say let's get the specification finished first, I'll continue with that ASAP! Cheers -Frank- J8) -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
[jira] [Closed] (FLEX-33230) Config file for frameworks/projects/spark
[ https://issues.apache.org/jira/browse/FLEX-33230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton closed FLEX-33230. - Resolution: Fixed Fix Version/s: (was: Apache Flex Next) Apache Flex 4.9.0 Fixed for Apache Flex 4.9. Config file for frameworks/projects/spark -- Key: FLEX-33230 URL: https://issues.apache.org/jira/browse/FLEX-33230 Project: Apache Flex Issue Type: Sub-task Components: SWC Generation (compc) Reporter: Chema Balsas Fix For: Apache Flex 4.9.0 Attachments: spark_compile.diff Conversion of compc task properties in frameworks/projects/spark/build.xml to config files. - Conversion of bundle macrodef - Conversion of compile target -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33228) Config files for frameworks/projects/rpc
[ https://issues.apache.org/jira/browse/FLEX-33228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton closed FLEX-33228. - Resolution: Fixed Config files for frameworks/projects/rpc Key: FLEX-33228 URL: https://issues.apache.org/jira/browse/FLEX-33228 Project: Apache Flex Issue Type: Sub-task Components: SWC Generation (compc) Reporter: Chema Balsas Attachments: rpc_compile.diff Conversion of compc task properties in frameworks/projects/rpc/build.xml to config files. - Conversion of bundle macrodef - Conversion of compile target -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33227) Config files for frameworks/projects/framework
[ https://issues.apache.org/jira/browse/FLEX-33227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton closed FLEX-33227. - Resolution: Fixed Fix Version/s: Apache Flex 4.9.0 Fixed for Apache Flex 4.9. Config files for frameworks/projects/framework -- Key: FLEX-33227 URL: https://issues.apache.org/jira/browse/FLEX-33227 Project: Apache Flex Issue Type: Sub-task Components: SWC Generation (compc) Reporter: Chema Balsas Fix For: Apache Flex 4.9.0 Attachments: framework_compile.diff Conversion of compc task properties in frameworks/projects/framework.build.xml to config files. - Conversion of bundle macrodef - Conversion of compile target -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33230) Config file for frameworks/projects/spark
[ https://issues.apache.org/jira/browse/FLEX-33230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton closed FLEX-33230. - Resolution: Fixed Fix Version/s: (was: Apache Flex Next) Apache Flex 4.9.0 Fixed for Apache Flex 4.9. Config file for frameworks/projects/spark -- Key: FLEX-33230 URL: https://issues.apache.org/jira/browse/FLEX-33230 Project: Apache Flex Issue Type: Sub-task Components: SWC Generation (compc) Reporter: Chema Balsas Fix For: Apache Flex 4.9.0 Attachments: spark_compile.diff Conversion of compc task properties in frameworks/projects/spark/build.xml to config files. - Conversion of bundle macrodef - Conversion of compile target -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33229) Config files for frameworks/projects/mx
[ https://issues.apache.org/jira/browse/FLEX-33229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton closed FLEX-33229. - Resolution: Fixed Fix Version/s: Apache Flex 4.9.0 Fixed for Apache Flex 4.9. Config files for frameworks/projects/mx --- Key: FLEX-33229 URL: https://issues.apache.org/jira/browse/FLEX-33229 Project: Apache Flex Issue Type: Sub-task Components: SWC Generation (compc) Reporter: Chema Balsas Fix For: Apache Flex 4.9.0 Attachments: mx_compile.diff, mx_compile.diff Conversion of compc task properties in frameworks/projects/mx/build.xml to config files. - Conversion of bundle macrodef - Conversion of compile target -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [FalconJx] MXML implementation notes
Quoting Erik de Bruin e...@ixsoftware.nl: On Mon, Jan 21, 2013 at 1:48 PM, Michael Schmalle apa...@teotigraphix.com wrote: he I'm not at all sure I understand the details of what you're discussing, so I'll just ask this one rookie question: will I be able to create something like a MXMLGoogEmitter.java to output the information in the MXML in a way that will let me interpret it the 'goog' way? HAHA! Erik, this is Mike you are talking to, now wouldn't it be pretty mean of me to only let one way exist for MXML production? ;-) Of course, I am writing things along the same lines as the AS visitors BUT there is a semantic difference that we are not exactly translating MXML AST to js, so I need a bit more time figuring out the abstractions. But it will be completely decoupled to where the backend will decide the MXML emitter. Mike Thanks, EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
[jira] [Closed] (FLEX-33132) Apache Flex 4.8.0 (parity release) Release Candidate
[
https://issues.apache.org/jira/browse/FLEX-33132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carol Frampton closed FLEX-33132.
-
Resolution: Fixed
Fix Version/s: Apache Flex 4.9.0
Closing. Apache Flex 4.9 has been released.
Apache Flex 4.8.0 (parity release) Release Candidate
Key: FLEX-33132
URL: https://issues.apache.org/jira/browse/FLEX-33132
Project: Apache Flex
Issue Type: Task
Components: Installation Packaging
Affects Versions: Apache Flex 4.8 (parity release)
Reporter: Carol Frampton
Fix For: Apache Flex 4.9.0
Attachments: rat.log, rat.report
Attached is the RAT report (rat.log) for the files in the source kit. The
current kits are available from
http://people.apache.org/~cframpton/ApacheFlexRC/current/
The exclusions from the report are:
fileset dir=${rat.dir}
!-- Start of binary files --
!-- exclude Flash Professional file used for integration
with Flash Professional --
exclude
name=frameworks/projects/flash-integration/FLA/ContentHolder.fla/
!-- exclude font embedded in asdoc example --
exclude
name=frameworks/projects/framework/asdoc/en_US/mx/effects/examples/assets/OpenSans-Regular.ttf/
!-- exclude media (png, gif, jpg, mp3, flv) --
exclude name=**/*.png/
exclude name=**/*.gif/
exclude name=**/*.jpg/
exclude name=**/*.mp3/
exclude name=**/*.flv/
!-- End of binary files --
!-- exclude batik manifests --
exclude name=modules/thirdparty/batik/sources/*.mf/
!-- exclude w3c sources --
exclude
name=modules/thirdparty/batik/resources/org/apache/flex/forks/batik/dom/svg/resources/*.mod/
exclude
name=modules/thirdparty/batik/resources/org/apache/flex/forks/batik/dom/svg/resources/*.dtd/
exclude
name=modules/thirdparty/batik/sources/org/w3c/flex/forks/css/sac/*.java/
exclude
name=modules/thirdparty/batik/sources/org/w3c/flex/forks/css/sac/helpers/ParserFactory.java/
!-- exclude config files --
exclude
name=modules/thirdparty/xerces-patch/src/java/META-INF/services/javax.xml.parsers.SAXParserFactory/
exclude
name=modules/thirdparty/xerces-patch/src/java/META-INF/services/org.apache.xerces.xni.parser.XMLParserConfiguration/
exclude
name=modules/thirdparty/xerces-patch/src/java/org/apache/xerces/jaxp/javax.xml.parsers.SAXParserFactory/
/fileset
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [FalconJx] MXML implementation notes
Mike, Just to ease my confused mind: Of course, I am writing things along the same lines as the AS visitors BUT there is a semantic difference that we are not exactly translating MXML AST to js, so I need a bit more time figuring out the abstractions. not EXACTLY translating, what does that mean? To what else but js will we be translating MXML? Won't I be able to emit this: s:Button id=myButton x=25 y=100 label=Click me / to: var myButton = new Button(); myButton.x = 25; myButton.y = 100; myButton.label = Click me; (overly simplified example, but you get my drift) EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] MXML implementation notes
Ok here is the deal. As of now Alex is using a descriptor type emittion. Creating init objects that initialize a DOM instance. So the ASJS emitter would load up a values object that when the component is created, is populated by those descriptors. Your method is different. Put it this way, I am not writing anything concrete with either right now. Last night I discovered there are a couple different ways to do this and I really need to be careful to not couple the walker with a certain implementation like I was just about to do with Alex's ASJS descriptors. I need a higher level and that is what I am working on. Basically with what I am writing, in your emitter, you will be able to visit and InstanceNode and create code like you have above. The instance node in MXML is the Button tag you wrote as an example. By doing this, I can also write an emitter that when it visits an InstanceNode for ALex, will create a descriptor of the properties he needs and save that into the descriptors array. Does this make sense? Mike Quoting Erik de Bruin e...@ixsoftware.nl: Mike, Just to ease my confused mind: Of course, I am writing things along the same lines as the AS visitors BUT there is a semantic difference that we are not exactly translating MXML AST to js, so I need a bit more time figuring out the abstractions. not EXACTLY translating, what does that mean? To what else but js will we be translating MXML? Won't I be able to emit this: s:Button id=myButton x=25 y=100 label=Click me / to: var myButton = new Button(); myButton.x = 25; myButton.y = 100; myButton.label = Click me; (overly simplified example, but you get my drift) EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] Compiling i18n properties / ResourceBundles
On 1/21/13 12:01 AM, Frank Wienberg fr...@jangaroo.net wrote: Besides ActionScript and MXML, there is a third source file format for which mxmlc can produce code: properties files. Thus, for FalconJx, like for MXML, we have to decide which way to go: either 1. let Falcon generate the temporary ActionScript class and compile that to JavaScript, or 2. produce JavaScript code or maybe even data (JSON?) directly from the properties file. Sorry, I didn't read the whole email, but I believe there is a 3rd option (and more) 3. Don't reduce string-only properties files to the current class structure, just take them in as a string and parse them in the framework. How often do folks actually use binary resources? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: pls add me in your list
On 1/21/13 5:49 AM, anurag anuraggupta@gmail.com wrote: pls add me in your list Instructions on how to do it yourself are on the main flex web site at flex.apache.org -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
JIRA filter to find patches
Justin, Will you please update your patches filter: https://issues.apache.org/jira/issues/?filter=12322839 to exclude CLOSED bugs. thanks, Carol
Re: [FlexJS] moved js library in SVN
On 1/21/13 6:06 AM, Erik de Bruin e...@ixsoftware.nl wrote: Mike, I looked through your committed code and see and AIR app there. hmmm.. Putting the horse before the cart are we? No, I'm not (if I understand the idiom correctly). I'm working on tying the work we did on FJx to the work I did on the JS publisher earlier. This should help Alex get a better sense of what's possible with FJx and make his case to the powers that be. There are no powers that be. Whatever the project decides to do is what we are going to do. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
[jira] [Commented] (FLEX-33169) Spark List selection on mobile doesn't work properly
[ https://issues.apache.org/jira/browse/FLEX-33169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558822#comment-13558822 ] Maurice Amsellem commented on FLEX-33169: - You are correct, it's asymetrical and makes the code harder to understand. However, as far as I can understand from reading the code, mouseDownPoint and mouseDownObject, although having similar names, have completely different purposes. mouseDownPoint is used for drag/drop and was already there in SDK 4.1 mouseDownObject seems to be a recent adding, and is only for managing selection vs. scrolling on mobile platforms. So that's why I didn't want to change mouseDownPoint as well. What do you think ? Spark List selection on mobile doesn't work properly Key: FLEX-33169 URL: https://issues.apache.org/jira/browse/FLEX-33169 Project: Apache Flex Issue Type: Bug Components: Spark: List Affects Versions: Adobe Flex SDK 4.5.1 (Release), Adobe Flex SDK 4.6 (Release) Environment: iOS 5.x, Android 3.2/4.0, Air 3.0 - 3.3 Reporter: Al Birdy Attachments: FLEX-33169_Mobile_List_Selection.patch, ListExt.as The touch selection of list items on the actual device does not work properly. Sometimes, even though the touch has definitely been recognized by the device, the list selection change isn't committed, instead the previously selected item remains selected. To reproduce the issue, please set up a new Flex mobile project and add the most basic list with inline renderer to a view: s:List id=myList width=100% height=100% s:dataProvider s:ArrayCollection fx:Object label=Item1 / . fx:Object label=Item30 / /s:ArrayCollection /s:dataProvider /s:List Deploy the app to an actual device (this bug does NOT appear in the emulator!) and randomly try to select items, scroll the list, select again and so on. You'll notice that the down color is sometimes set, but the selection isn't changed. For a more detailed description of this bug please see http://stackoverflow.com/questions/11740074/selection-on-spark-mobile-list-only-works-3-out-of-4-times -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: we need to better document the patch process
Yes, very nice except we need to be more specific about creating a patch. They really should be from root. Carol On 1/21/13 10 :19AM, Nicholas Kwiatkowski nicho...@spoon.as wrote: Carol, Is this page any better : http://flex.apache.org/v2/community-getinvolved.html -Nick On Mon, Jan 21, 2013 at 10:05 AM, Carol Frampton cfram...@adobe.com wrote: Good morning, Ever time I go to apply a patch to take a look at the code, it has failed for various reasons. I took a quick look at our website and I didn't see anywhere obvious where we document how to generate a patch to attach to a JIRA bug. Did I overlook it? If so, we need to make it more obvious. If we haven't documented it we need to do that. I would suggest on the Source Code page we might want to nicely state that only commitors can commit to SVN, otherwise a patch needs to be added to a JIRA bug and then explain how to generate the patch. They should be created with svn and generated from root. Carol
Re: we need to better document the patch process
If you wouldn't mind updating the language in that page, that would help out a lot. I rely on the integrated SVN tools in my IDEs to be much use ;) -Nick On Mon, Jan 21, 2013 at 10:24 AM, Carol Frampton cfram...@adobe.com wrote: Yes, very nice except we need to be more specific about creating a patch. They really should be from root. Carol On 1/21/13 10 :19AM, Nicholas Kwiatkowski nicho...@spoon.as wrote: Carol, Is this page any better : http://flex.apache.org/v2/community-getinvolved.html -Nick On Mon, Jan 21, 2013 at 10:05 AM, Carol Frampton cfram...@adobe.com wrote: Good morning, Ever time I go to apply a patch to take a look at the code, it has failed for various reasons. I took a quick look at our website and I didn't see anywhere obvious where we document how to generate a patch to attach to a JIRA bug. Did I overlook it? If so, we need to make it more obvious. If we haven't documented it we need to do that. I would suggest on the Source Code page we might want to nicely state that only commitors can commit to SVN, otherwise a patch needs to be added to a JIRA bug and then explain how to generate the patch. They should be created with svn and generated from root. Carol
[jira] [Commented] (FLEX-14658) Drop feedback still showing after call to hideDropFeedback
[ https://issues.apache.org/jira/browse/FLEX-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558848#comment-13558848 ] Sébastien Kafif commented on FLEX-14658: I found a workaround for that bug how can I propose it ? Drop feedback still showing after call to hideDropFeedback -- Key: FLEX-14658 URL: https://issues.apache.org/jira/browse/FLEX-14658 Project: Apache Flex Issue Type: Bug Components: Drag and Drop Affects Versions: Adobe Flex SDK 3.0 (Release) Environment: Affected OS(s): Mac Affected OS(s): Mac OS 10.5 Browser: Firefox 2.x Language Found: English Reporter: Adobe JIRA These are the reproduction steps when running the application in the attached file: DragAndDropTest.mxml Steps to reproduce: 1. Drag and drop 4 rows from the source grid to the target grid. 2. Drag 1 more row from the source grid, and position the drop point either before the last row or after the last row. 3. Drop the row onto the target grid. 4. Watch the target grid drop feedback continue to display after the drop. Actual Results: The drop feedback on the target grid (grid border color and drop position indicator) continues to display after the drop is complete. Expected Results: The target grid's drop indicator should stop displaying after the drop is complete. Workaround (if any): None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Stage3D accelerated Flex components
I'm on mobile, so please forgive my terseness and Typos' What I meant is that it doesn't conceptually make sense to me to have one server code that works in cpu mode and another server code that works in GPU mode. Same with memory management. For the record the tone was clear to me. On Jan 21, 2013 5:38 PM, Nick Collins ndcoll...@gmail.com wrote: I haven't seen anybody in the group expect any one person to do everything for them. That kind of flies in the face of the whole concept of being an Apache project. I think that your point, while it has some validity, probably didn't need to be verbalized until there was a problem. Otherwise it comes across as an insinuation that the group at large is just a bunch of parasites looking to leach off your hard work. Kind of leaves a bad taste in one's mouth that might cause folks to dismiss your suggestion, whether it has technical merit or not ( and I believe it very well may ). Nick On Mon, Jan 21, 2013 at 7:25 AM, Daniel Freeman madcompone...@gmail.com wrote: @Mike, I've updated my wording slightly. But it's getting late (Brisbane time), and I'll see how things look in the morning. I don't apologies for carefully qualifying my expected contributions, and my expectations of other people's contribution. While I've changed the wording and dressed it up a little differently - I'm still not willing to write all of this for you - with no contribution from this group. As MadComponents has became popular - there's been increasing expectation on me to maintain, enhance, and support developers using it. While I've tried to share the burden with other developers - I've still had to contribute more time to this project than I've been comfortable with.
Re: [FalconJx] MXML implementation notes
Quoting Alex Harui aha...@adobe.com:
There are probably a lot of other MXML-isms like the classfactory handling.
But my hope is to get rid of as many as we can. Most if not all of this
code gen can be handled better by code in the framework interpreting data.
Really, if was practical to generate code on the fly in AS,
What do you mean generate code on the fly, you mean ABC bytecode
during runtime in the player?
I wouldn't
convert MXML at all, I would just suck it in as XML and parse it at runtime.
It would make for much smaller SWFs and take advantage of the JIT by making
the parsing loop hotter. Right now, Flex MXML generates lots of run-once
methods.
I'm keeping .js in mind for mxml as well so I guess this is just mute
point right now.
Binding is tricky only because I want to encode it as well. We don't want
to generate the current anonymous function wrappers for simple binding
expressions.
Yeah, for now I am not thinking about this stuff, I am getting the
walker and visitor pattern API setup so there can be different
implementations just like there is in AS.
Although it is about 2-3 times harder in MXML because I have to be
able to generate AS inside the MXML, I'm getting something working and
the concept seems solid to me.
I'll put together a spec on the wiki about the data format. You might be
able to guess it from the MXMLDataInterpreter class.
Yeah I noticed that class last night, it would be nice to read
something you write though.
Mike
On 1/21/13 4:48 AM, Michael Schmalle apa...@teotigraphix.com wrote:
Alex,
Responding inline would be to much of a mess.
Basically half of my post was about the data spec. So you asking if I
am looking for the data spec, my answer would be yes.
I'm just trying to write a list of things I need to generate.
To reiterate, I understand we are generating data structures, descriptors.
We have to generate
- wrappers for event handlers
- conceptually seems pretty straightforward
- deal with inner classes
- What do you mean inner classes, the Component tag?
- script blocks
- these are IASNodes that are directly on the tree, this should not
be hard, the way the current block emitter is setup with visit methods
can push this stuff out right in the TypeScope
- CSS
- No idea right now, needs more thought
- binding syntax
- Since I have good ActionScript emitting, I can't see how the {}
syntax in an attribute would be hard to generate. I may be
underthinking but I really think that is doable soon.
I will post any more direct questions I may have when I encounter them.
Mike
Quoting Alex Harui aha...@adobe.com:
On 1/20/13 1:50 PM, Michael Schmalle apa...@teotigraphix.com wrote:
Hi,
Alex this one is aimed at you. I have been studying what you have done
for the whole day today and managed by copying about 1000 various
lines of code to my prototype MXML emitter got your Fragment lists to
be populated by my traversal.
Now the question is, can you in about 5-6 paragraphs give me a nice
detailed approach of yours with what is needed.
For example, I see;
- The main application mxml file, this looks as though it's getting
translated pretty vanilla.
Not sure what you mean by that. For sure, I might have missed generating
some pattern the goog way. But it seemed like most of the
goog-ness is in
the class and method signatures not in the function body, but I might have
missed something there.
- you are renaming with the dummy post fix, why?
I am? I didn't think so. Also remember, lots of this code is not mine so
it might be doing something I'm not aware of.
- in the constructor you are just using the InstanceNode values (I
know this is all being done behind the scenes, I get how the
directives work now and are processed recursively)
The constructor stuff could need work. I didn't do too much in the way the
constructor is reduced and mostly changed the way it gets emitted.
- The MyInitialView is sketchy, is uiDescriptors being created by you
or is that property created by the MXMLClassDirective?
MXMLClassDirective is the old-school code-gen. I have altered code paths in
many of the methods by adding the mxml.children-as-data flag. That causes
MXMLClassDirective to spit out the MXMLDescriptors and
MXMLProperties arrays
that contain a description of the MXML tags. We are not going to use the
old code-gen: we will require this flag be set. But the AS code
can consume
this kind of output, and I have a similar interpreter for the old SDK code.
JSMXMLClassDirective then just tries to transcode this stuff into JS.
- Same with he event handlers, I see that is being take care of by the
process method.
I really think if you can give me as much information of what you are
doing and need, I could have FalconJx producing the MXML sooner than
later. As I said I already have it spinning, just need to know exactly
what you need at the moment.
I'm not 100% sure what you are looking
Re: [FalconJx] MXML implementation notes
On 1/21/13 9:02 AM, Michael Schmalle apa...@teotigraphix.com wrote: Quoting Alex Harui aha...@adobe.com: There are probably a lot of other MXML-isms like the classfactory handling. But my hope is to get rid of as many as we can. Most if not all of this code gen can be handled better by code in the framework interpreting data. Really, if was practical to generate code on the fly in AS, What do you mean generate code on the fly, you mean ABC bytecode during runtime in the player? Yes. Technically I know it is possible, and believe me, I have thought about leveraging it at times. I wouldn't convert MXML at all, I would just suck it in as XML and parse it at runtime. It would make for much smaller SWFs and take advantage of the JIT by making the parsing loop hotter. Right now, Flex MXML generates lots of run-once methods. I'm keeping .js in mind for mxml as well so I guess this is just mute point right now. I believe js performance will also benefit from re-use of code vs lots of run-once methods. I'll put together a spec on the wiki about the data format. You might be able to guess it from the MXMLDataInterpreter class. Yeah I noticed that class last night, it would be nice to read something you write though. Okeydokey. Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
[jira] [Commented] (FLEX-29002) RunTime Error #1009 at mx.managers::PopUpManagerImpl/addModalPopUpAccessibility() when displaying more than one modal popup via PopUpManager on top of each other. On Wi
[ https://issues.apache.org/jira/browse/FLEX-29002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558917#comment-13558917 ] Carol Frampton commented on FLEX-29002: --- Because a fix was checked in after mine and removed by fix. I expect is was a merge issue and wasn't intentional. RunTime Error #1009 at mx.managers::PopUpManagerImpl/addModalPopUpAccessibility() when displaying more than one modal popup via PopUpManager on top of each other. On Windows 7 running on some PCs --- Key: FLEX-29002 URL: https://issues.apache.org/jira/browse/FLEX-29002 Project: Apache Flex Issue Type: Bug Components: PopUp Manager Affects Versions: Adobe Flex SDK Previous Environment: Affected OS(s): Windows Affected OS(s): Windows 7 Language Found: English Reporter: Adobe JIRA Assignee: Carol Frampton Fix For: Adobe Flex SDK Next Steps to reproduce: 1. in the AIR application, create modal popup via popupmanager - ok. 2. on the popup, create another modal popup via popupmanager (so we have two modal popups one on top of the other) - RT error #1009. 3. close top popup, due to RT error #1009 modal shade stays on stage and keeps blocking the application. Actual Results: Popupmanager closes modal titlewindow, but the modal shade stays on display due to RunTime error #1009 and so application becomes non-operable. Expected Results: Popupmanager should close the modal titlewindow along with the modal shade as it does if only one modal popup was invoked. Workaround (if any): On Windows7 Control Panel, disable some stuff in control panel (Attachments) and reboot OS. Trully, this works. Note: This happens only on Windows 7 OS running on some All-In-One PCs (eg.: MSI AE2050). Bug is connected with the accessibility OS provides, so we can fix the issue by configuring some OS parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (FLEX-29002) RunTime Error #1009 at mx.managers::PopUpManagerImpl/addModalPopUpAccessibility() when displaying more than one modal popup via PopUpManager on top of each other. On Win
[ https://issues.apache.org/jira/browse/FLEX-29002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton reopened FLEX-29002: --- RunTime Error #1009 at mx.managers::PopUpManagerImpl/addModalPopUpAccessibility() when displaying more than one modal popup via PopUpManager on top of each other. On Windows 7 running on some PCs --- Key: FLEX-29002 URL: https://issues.apache.org/jira/browse/FLEX-29002 Project: Apache Flex Issue Type: Bug Components: PopUp Manager Affects Versions: Adobe Flex SDK Previous Environment: Affected OS(s): Windows Affected OS(s): Windows 7 Language Found: English Reporter: Adobe JIRA Assignee: Carol Frampton Fix For: Adobe Flex SDK Next Steps to reproduce: 1. in the AIR application, create modal popup via popupmanager - ok. 2. on the popup, create another modal popup via popupmanager (so we have two modal popups one on top of the other) - RT error #1009. 3. close top popup, due to RT error #1009 modal shade stays on stage and keeps blocking the application. Actual Results: Popupmanager closes modal titlewindow, but the modal shade stays on display due to RunTime error #1009 and so application becomes non-operable. Expected Results: Popupmanager should close the modal titlewindow along with the modal shade as it does if only one modal popup was invoked. Workaround (if any): On Windows7 Control Panel, disable some stuff in control panel (Attachments) and reboot OS. Trully, this works. Note: This happens only on Windows 7 OS running on some All-In-One PCs (eg.: MSI AE2050). Bug is connected with the accessibility OS provides, so we can fix the issue by configuring some OS parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FLEX-29002) RunTime Error #1009 at mx.managers::PopUpManagerImpl/addModalPopUpAccessibility() when displaying more than one modal popup via PopUpManager on top of each other. On Win
[ https://issues.apache.org/jira/browse/FLEX-29002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton resolved FLEX-29002. --- Resolution: Fixed Fix Version/s: Apache Flex 4.10.0 Author: cframpton Date: Mon Jan 21 17:14:14 2013 New Revision: 1436492 URL: http://svn.apache.org/viewvc?rev=1436492view=rev Log: FLEX-29002. Reapply 1398487 which was wiped out by the next change to the file. Modified: flex/sdk/branches/develop/frameworks/projects/framework/src/mx/managers/PopUpManagerImpl.as RunTime Error #1009 at mx.managers::PopUpManagerImpl/addModalPopUpAccessibility() when displaying more than one modal popup via PopUpManager on top of each other. On Windows 7 running on some PCs --- Key: FLEX-29002 URL: https://issues.apache.org/jira/browse/FLEX-29002 Project: Apache Flex Issue Type: Bug Components: PopUp Manager Affects Versions: Adobe Flex SDK Previous Environment: Affected OS(s): Windows Affected OS(s): Windows 7 Language Found: English Reporter: Adobe JIRA Assignee: Carol Frampton Fix For: Adobe Flex SDK Next, Apache Flex 4.10.0 Steps to reproduce: 1. in the AIR application, create modal popup via popupmanager - ok. 2. on the popup, create another modal popup via popupmanager (so we have two modal popups one on top of the other) - RT error #1009. 3. close top popup, due to RT error #1009 modal shade stays on stage and keeps blocking the application. Actual Results: Popupmanager closes modal titlewindow, but the modal shade stays on display due to RunTime error #1009 and so application becomes non-operable. Expected Results: Popupmanager should close the modal titlewindow along with the modal shade as it does if only one modal popup was invoked. Workaround (if any): On Windows7 Control Panel, disable some stuff in control panel (Attachments) and reboot OS. Trully, this works. Note: This happens only on Windows 7 OS running on some All-In-One PCs (eg.: MSI AE2050). Bug is connected with the accessibility OS provides, so we can fix the issue by configuring some OS parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FLEX-33064) The Max value restriction in Spark NumericStepper doesn't work properly
[ https://issues.apache.org/jira/browse/FLEX-33064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carol Frampton reassigned FLEX-33064: - Assignee: Carol Frampton The Max value restriction in Spark NumericStepper doesn't work properly --- Key: FLEX-33064 URL: https://issues.apache.org/jira/browse/FLEX-33064 Project: Apache Flex Issue Type: Bug Components: Project Management Environment: Apache FlexSDK 4.6 - Adobe FlexSDK 4.6 - Adobe FlexSDK 4.5 Reporter: Alex Harui Assignee: Carol Frampton Priority: Minor Labels: patch Attachments: NumericStepperPatch.txt original issue: https://bugs.adobe.com/jira/browse/SDK-31123 here a summary: Steps to reproduce: 1.Launch the browser with Numeric stepper. Set the min value as 10 max value as 50. Also set default values as 20. 2.After launching the broswer clear the default value 20 and focus out from the numeric stepper. It displays NAN 3. Again focus back to the numeric stepper and try to edit 3 digit value (Eg.777). Then foucs out. It doen't restrict to max value i.e50 as set earlier in step 1. It allows the 3 digit value enetered instead. Actual Results: The enetered value will be displayed Expected Results: It should restrict and display the max values as set in step 1. Workaround (if any): No Work around. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compiling MXMLs
That said; did you compile the SDK yourself or use the installer?
If you compiled yourself, then be sure to read the release notes:
http://www.apache.org/dist/flex/4.9.0/README . Pay specific attention
to the install prerequisites. Did you download the playerGlobal.swc
from Adobe and put it in the proper directory? IF not; that is why it
cannot be found.
Also, be sure to check our the Apache Flex users list (
http://flex.apache.org/mailing-lists.html ). The Dev list is about the
development of the SDK; whereas the users list is intended as a place
where users of the SDK can go get help.
On 1/21/2013 12:40 PM, Angelo Anolin wrote:
Hi,
I haven't completely subscribed to the development of things so I need to
ask some few questions with regards to MXML compilations.
Previously (using Flex SDK 4.5), I compile my MXMLs like:
mxmlc -static-link-runtime-shared-libraries=false FILENAME.mxml
-output=\\MyOutputFolder -library-path+=MyComponent.swc
I just want to ask if what's the suggested way of compiling MXMLs through
the command line now?
I Just tried executing the above command line and I got the error:
Error: Unable to open '{playerglobalHome}/11.1/playerglobal.swc'
Current SDK I am using is
Version 4.90 Build 1425567
Appreciate your guidance.
Thank you.
Kind regards,
Angelo
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
[jira] [Commented] (FLEX-33354) [button] define the placement of icon (iconPlacement) in skin [ButtonSkin]
[ https://issues.apache.org/jira/browse/FLEX-33354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13558951#comment-13558951 ] Marcus Fritze commented on FLEX-33354: -- Per default the SparkButtonSkin (and not SparkSkin) will be used, when I create a Skin for a Button. (As you mentioned, I don't know if this is a bug.) But you are right, the SparkSkin is working for my Skin. Thanks! [button] define the placement of icon (iconPlacement) in skin [ButtonSkin] -- Key: FLEX-33354 URL: https://issues.apache.org/jira/browse/FLEX-33354 Project: Apache Flex Issue Type: Brainstorming Components: Spark: Button, Spark: ToggleButton Affects Versions: Apache Flex 4.9.0 Reporter: Marcus Fritze Priority: Minor I think it would be better to define the placement of the icon in the button via Skin. Currently, we set iconPlacement (left, right, bottom, top). I realized that the iconDisplay is a SkinPart since Flex 4.5, but I can't see it in the default ButtonSkin. And the layout of the icon, label and custom skin-parts is wrong when I use the icon and a Custom Skin for the Spark Button / ToggleButton. Why isn't the iconDisplay in the ButtonSkin? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FLEX-33354) [button] define the placement of icon (iconPlacement) in skin [ButtonSkin]
[ https://issues.apache.org/jira/browse/FLEX-33354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Fritze closed FLEX-33354. Resolution: Not A Problem [button] define the placement of icon (iconPlacement) in skin [ButtonSkin] -- Key: FLEX-33354 URL: https://issues.apache.org/jira/browse/FLEX-33354 Project: Apache Flex Issue Type: Brainstorming Components: Spark: Button, Spark: ToggleButton Affects Versions: Apache Flex 4.9.0 Reporter: Marcus Fritze Priority: Minor I think it would be better to define the placement of the icon in the button via Skin. Currently, we set iconPlacement (left, right, bottom, top). I realized that the iconDisplay is a SkinPart since Flex 4.5, but I can't see it in the default ButtonSkin. And the layout of the icon, label and custom skin-parts is wrong when I use the icon and a Custom Skin for the Spark Button / ToggleButton. Why isn't the iconDisplay in the ButtonSkin? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [FalconJx] MXML implementation notes
Gordon, every time you reply to something I say, it seems like I'm offending you. I really am not. :) What I meant to say was ActionScript AST flows naturally out to String source code, where as MXML requires pre and post processing of the AST to make total sense of what you might produce. The AST itself is not ugly, its the processing of it and making sens of it the way you need it. I'm too poetic sometimes and I apologize for that. I spent the last day studying the MXMLClassDirectiveProccessor and fully understand how to traverse the MXML AST. So sorry for the misunderstanding, I didn't mean the AST is an ugly duckling. Mike Quoting Gordon Smith gosm...@adobe.com: MXML is an ugly duckling compared to surfing the AS AST What issues are you referring to? - Gordon -Original Message- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Sunday, January 20, 2013 1:50 PM To: dev@flex.apache.org Subject: [FalconJx] MXML implementation notes Hi, Alex this one is aimed at you. I have been studying what you have done for the whole day today and managed by copying about 1000 various lines of code to my prototype MXML emitter got your Fragment lists to be populated by my traversal. Now the question is, can you in about 5-6 paragraphs give me a nice detailed approach of yours with what is needed. For example, I see; - The main application mxml file, this looks as though it's getting translated pretty vanilla. - you are renaming with the dummy post fix, why? - in the constructor you are just using the InstanceNode values (I know this is all being done behind the scenes, I get how the directives work now and are processed recursively) - The MyInitialView is sketchy, is uiDescriptors being created by you or is that property created by the MXMLClassDirective? - Same with he event handlers, I see that is being take care of by the process method. I really think if you can give me as much information of what you are doing and need, I could have FalconJx producing the MXML sooner than later. As I said I already have it spinning, just need to know exactly what you need at the moment. Also, this is where the framework will work out nice since when I need to emit ActionScript for the MXML, I will pass it the current emitter and send it through the ASBlockWalker. I will also be honest and say, MXML is an ugly duckling compared to surfing the AS AST, so when I say I can get your code working sooner than later, I really mean I can get exactly what you have, to prove we have all the right tools to put effort into the FalconJx version because it will produce everything we need. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
RE: [FalconJx] MXML implementation notes
Don't worry about offending me... I'm reasonably thick-skinned. If there's a better way to do something, I want to know about it. MXMLData provides a pure-syntax model of MXML. By contrast, an MXML AST encodes the semantic meaning of the MXML, in a way that makes it straightforward to codegen. In AS, an expression, statement, or declaration has pretty much the same meaning at any level of a program. But in MXML, the meaning of a tag or attribute in the middle of an MXML file can only be determined by a top-down walk, resolving tags like s:Button to their corresponding class in order to determine the properties, styles, and events of that class. So the tree-building phase is in fact also a semantic analysis phase (with many MXML problems currently not getting reported). An example of the ambiguities in MXML is Foo barwhatever/bar /Foo In MXML, this could mean a wide variety of things, depending on where this snippet appears and how tags resolve, such as 1. Create a Foo instance and set its 'bar' property to whatever. 2. Create a Foo instance and set its 'bar' style to whatever. 3. Create a Foo instance and set its default property to an instance of bar, where the default property of 'bar' has the value whatever. 4. Set the Foo property of the enclosing instance to an instance of 'bar', where the default property of 'bar' has the value whatever. These ambiguities are tamed a little by conventions such as starting classes with a capital letter and properties/styles/ events with a lower-case letter, but these are only conventions, and are sometimes ignored such as with p representing an instance of ParameterElement in TLF. - Gordon -Original Message- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Monday, January 21, 2013 10:19 AM To: dev@flex.apache.org Subject: RE: [FalconJx] MXML implementation notes Gordon, every time you reply to something I say, it seems like I'm offending you. I really am not. :) What I meant to say was ActionScript AST flows naturally out to String source code, where as MXML requires pre and post processing of the AST to make total sense of what you might produce. The AST itself is not ugly, its the processing of it and making sens of it the way you need it. I'm too poetic sometimes and I apologize for that. I spent the last day studying the MXMLClassDirectiveProccessor and fully understand how to traverse the MXML AST. So sorry for the misunderstanding, I didn't mean the AST is an ugly duckling. Mike Quoting Gordon Smith gosm...@adobe.com: MXML is an ugly duckling compared to surfing the AS AST What issues are you referring to? - Gordon -Original Message- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Sunday, January 20, 2013 1:50 PM To: dev@flex.apache.org Subject: [FalconJx] MXML implementation notes Hi, Alex this one is aimed at you. I have been studying what you have done for the whole day today and managed by copying about 1000 various lines of code to my prototype MXML emitter got your Fragment lists to be populated by my traversal. Now the question is, can you in about 5-6 paragraphs give me a nice detailed approach of yours with what is needed. For example, I see; - The main application mxml file, this looks as though it's getting translated pretty vanilla. - you are renaming with the dummy post fix, why? - in the constructor you are just using the InstanceNode values (I know this is all being done behind the scenes, I get how the directives work now and are processed recursively) - The MyInitialView is sketchy, is uiDescriptors being created by you or is that property created by the MXMLClassDirective? - Same with he event handlers, I see that is being take care of by the process method. I really think if you can give me as much information of what you are doing and need, I could have FalconJx producing the MXML sooner than later. As I said I already have it spinning, just need to know exactly what you need at the moment. Also, this is where the framework will work out nice since when I need to emit ActionScript for the MXML, I will pass it the current emitter and send it through the ASBlockWalker. I will also be honest and say, MXML is an ugly duckling compared to surfing the AS AST, so when I say I can get your code working sooner than later, I really mean I can get exactly what you have, to prove we have all the right tools to put effort into the FalconJx version because it will produce everything we need. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
RE: [FalconJx] MXML implementation notes
Right, hear you loud and clear. That is why am I taking the same strategy the MXMLClassDirectiveProccessor does and use the MXML AST over the MXMLData since I do understand how that tree is created and need the semantics already applied. With the ActionScript emitter I just wrote, combining it with the traversing and emitting is turning out to be a joy right now. I will have something committed in a while that ties both APIs together where the MXML uses the current walker and emitter for ActionScript so it can produce js in Script blocks etc. if that is what the intended output needs. Anyway, thanks for your explanation again! I am always willing to read insights from you, as it helps me along my path. Mike Quoting Gordon Smith gosm...@adobe.com: Don't worry about offending me... I'm reasonably thick-skinned. If there's a better way to do something, I want to know about it. MXMLData provides a pure-syntax model of MXML. By contrast, an MXML AST encodes the semantic meaning of the MXML, in a way that makes it straightforward to codegen. In AS, an expression, statement, or declaration has pretty much the same meaning at any level of a program. But in MXML, the meaning of a tag or attribute in the middle of an MXML file can only be determined by a top-down walk, resolving tags like s:Button to their corresponding class in order to determine the properties, styles, and events of that class. So the tree-building phase is in fact also a semantic analysis phase (with many MXML problems currently not getting reported). An example of the ambiguities in MXML is Foo barwhatever/bar /Foo In MXML, this could mean a wide variety of things, depending on where this snippet appears and how tags resolve, such as 1. Create a Foo instance and set its 'bar' property to whatever. 2. Create a Foo instance and set its 'bar' style to whatever. 3. Create a Foo instance and set its default property to an instance of bar, where the default property of 'bar' has the value whatever. 4. Set the Foo property of the enclosing instance to an instance of 'bar', where the default property of 'bar' has the value whatever. These ambiguities are tamed a little by conventions such as starting classes with a capital letter and properties/styles/ events with a lower-case letter, but these are only conventions, and are sometimes ignored such as with p representing an instance of ParameterElement in TLF. - Gordon -Original Message- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Monday, January 21, 2013 10:19 AM To: dev@flex.apache.org Subject: RE: [FalconJx] MXML implementation notes Gordon, every time you reply to something I say, it seems like I'm offending you. I really am not. :) What I meant to say was ActionScript AST flows naturally out to String source code, where as MXML requires pre and post processing of the AST to make total sense of what you might produce. The AST itself is not ugly, its the processing of it and making sens of it the way you need it. I'm too poetic sometimes and I apologize for that. I spent the last day studying the MXMLClassDirectiveProccessor and fully understand how to traverse the MXML AST. So sorry for the misunderstanding, I didn't mean the AST is an ugly duckling. Mike Quoting Gordon Smith gosm...@adobe.com: MXML is an ugly duckling compared to surfing the AS AST What issues are you referring to? - Gordon -Original Message- From: Michael Schmalle [mailto:apa...@teotigraphix.com] Sent: Sunday, January 20, 2013 1:50 PM To: dev@flex.apache.org Subject: [FalconJx] MXML implementation notes Hi, Alex this one is aimed at you. I have been studying what you have done for the whole day today and managed by copying about 1000 various lines of code to my prototype MXML emitter got your Fragment lists to be populated by my traversal. Now the question is, can you in about 5-6 paragraphs give me a nice detailed approach of yours with what is needed. For example, I see; - The main application mxml file, this looks as though it's getting translated pretty vanilla. - you are renaming with the dummy post fix, why? - in the constructor you are just using the InstanceNode values (I know this is all being done behind the scenes, I get how the directives work now and are processed recursively) - The MyInitialView is sketchy, is uiDescriptors being created by you or is that property created by the MXMLClassDirective? - Same with he event handlers, I see that is being take care of by the process method. I really think if you can give me as much information of what you are doing and need, I could have FalconJx producing the MXML sooner than later. As I said I already have it spinning, just need to know exactly what you need at the moment. Also, this is where the framework will work out nice since when I need to emit ActionScript for the MXML, I will pass it the current emitter
RE: [Marketing] - publicity
In response to the publicity we released a couple of weeks ago, we received request from the Software Editor from the Register, Gavin Clark, who wants to speak to one of the Apache Flex team members. Here is a link to the article he wrote [1] These were his questions: Thanks for getting in touch. Yes - would be good to speak to somebody on the Flex team to find out more - especially on where the project is and where it's heading. Let me know what you can arrange. Best Gavin Here is Gavin's contact information: Gavin Clarke, Software Editor The Register, UK Editorial The Communications Building 3rd Floor 48 Leicester Square London WC2H 7LT Would someone like to volunteer to speak to / communicate with Gavin to help him get his questions answered? [1] http://www.theregister.co.uk/2013/01/14/adobe_flex_apache/
[jira] [Commented] (FLEX-14658) Drop feedback still showing after call to hideDropFeedback
[ https://issues.apache.org/jira/browse/FLEX-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559001#comment-13559001 ] Carol Frampton commented on FLEX-14658: --- Add your workaround here. Drop feedback still showing after call to hideDropFeedback -- Key: FLEX-14658 URL: https://issues.apache.org/jira/browse/FLEX-14658 Project: Apache Flex Issue Type: Bug Components: Drag and Drop Affects Versions: Adobe Flex SDK 3.0 (Release) Environment: Affected OS(s): Mac Affected OS(s): Mac OS 10.5 Browser: Firefox 2.x Language Found: English Reporter: Adobe JIRA These are the reproduction steps when running the application in the attached file: DragAndDropTest.mxml Steps to reproduce: 1. Drag and drop 4 rows from the source grid to the target grid. 2. Drag 1 more row from the source grid, and position the drop point either before the last row or after the last row. 3. Drop the row onto the target grid. 4. Watch the target grid drop feedback continue to display after the drop. Actual Results: The drop feedback on the target grid (grid border color and drop position indicator) continues to display after the drop is complete. Expected Results: The target grid's drop indicator should stop displaying after the drop is complete. Workaround (if any): None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Marketing] - publicity
On Mon, Jan 21, 2013 at 11:03 AM, Guthmann, Scott sguthm...@on3solutions.com wrote: In response to the publicity we released a couple of weeks ago, we received request from the Software Editor from the Register, Gavin Clark, who wants to speak to one of the Apache Flex team members. Here is a link to the article he wrote [1] These were his questions: Thanks for getting in touch. Yes - would be good to speak to somebody on the Flex team to find out more - especially on where the project is and where it's heading. Let me know what you can arrange. Best Gavin Here is Gavin's contact information: Gavin Clarke, Software Editor The Register, UK Editorial The Communications Building 3rd Floor 48 Leicester Square London WC2H 7LT Would someone like to volunteer to speak to / communicate with Gavin to help him get his questions answered? [1] http://www.theregister.co.uk/2013/01/14/adobe_flex_apache/ I can talk to the editor. For the record, my response to where the project is would be: We have just graduated as a Top level project at the Apache Software Foundation. We have made two releases of the SDK as Apache Flex (4.8 and 4.9) and two releases of the SDK Installer (1.0 and 2.0) We have a bunch of new components and bug fixes that will be going into the next release - 4.10 which does not have a release date yet. To the question: where it's heading: Wherever the Apache Flex community wants to go. Specifically, there is a lot of work going on in the area of cross-compiling ActionScript/Flex code to Javascript and HTML5 to target web and mobile browsers. Work on tools and utilities (for testing, Maven support, mobile tests for Mustella etc.) is high on our list. And as always, there is a constant stream of bug fixes and additional locales coming in. The goal of Apache Flex would be to continue to maintain its status as one of the best cross-platform application development frameworks out there. And we are here to stay! Thanks, Om
[jira] [Commented] (FLEX-14658) Drop feedback still showing after call to hideDropFeedback
[ https://issues.apache.org/jira/browse/FLEX-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559017#comment-13559017 ] Sébastien Kafif commented on FLEX-14658: when you use dragDrop DataGrid property, the useCapture property of the addEventListener is set to false by default... If you add in actionscript the addEventListener like this : targetDatagrid.addEventListener(DragEvent.DragDrop, yourCallBack, true, 0, false); it won''t bug Drop feedback still showing after call to hideDropFeedback -- Key: FLEX-14658 URL: https://issues.apache.org/jira/browse/FLEX-14658 Project: Apache Flex Issue Type: Bug Components: Drag and Drop Affects Versions: Adobe Flex SDK 3.0 (Release) Environment: Affected OS(s): Mac Affected OS(s): Mac OS 10.5 Browser: Firefox 2.x Language Found: English Reporter: Adobe JIRA These are the reproduction steps when running the application in the attached file: DragAndDropTest.mxml Steps to reproduce: 1. Drag and drop 4 rows from the source grid to the target grid. 2. Drag 1 more row from the source grid, and position the drop point either before the last row or after the last row. 3. Drop the row onto the target grid. 4. Watch the target grid drop feedback continue to display after the drop. Actual Results: The drop feedback on the target grid (grid border color and drop position indicator) continues to display after the drop is complete. Expected Results: The target grid's drop indicator should stop displaying after the drop is complete. Workaround (if any): None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [FalconJx] Compiling i18n properties / ResourceBundles
Isn't that similar to the maybe even data (JSON?) part of option 2? Then the data would simply be the original properties file. I just thought as we have a compile/build step anyway, JSON would be much easier to parse in JavaScript (built-in!) than a properties file. On Mon, Jan 21, 2013 at 3:52 PM, Alex Harui aha...@adobe.com wrote: On 1/21/13 12:01 AM, Frank Wienberg fr...@jangaroo.net wrote: Besides ActionScript and MXML, there is a third source file format for which mxmlc can produce code: properties files. Thus, for FalconJx, like for MXML, we have to decide which way to go: either 1. let Falcon generate the temporary ActionScript class and compile that to JavaScript, or 2. produce JavaScript code or maybe even data (JSON?) directly from the properties file. Sorry, I didn't read the whole email, but I believe there is a 3rd option (and more) 3. Don't reduce string-only properties files to the current class structure, just take them in as a string and parse them in the framework. How often do folks actually use binary resources? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
[jira] [Updated] (FLEX-14658) Drop feedback still showing after call to hideDropFeedback
[ https://issues.apache.org/jira/browse/FLEX-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Kafif updated FLEX-14658: --- Attachment: DragDropBugged.mxml Here is file to test the bug Drop feedback still showing after call to hideDropFeedback -- Key: FLEX-14658 URL: https://issues.apache.org/jira/browse/FLEX-14658 Project: Apache Flex Issue Type: Bug Components: Drag and Drop Affects Versions: Adobe Flex SDK 3.0 (Release) Environment: Affected OS(s): Mac Affected OS(s): Mac OS 10.5 Browser: Firefox 2.x Language Found: English Reporter: Adobe JIRA Attachments: DragDropBugged.mxml, DragDropFixed.mxml These are the reproduction steps when running the application in the attached file: DragAndDropTest.mxml Steps to reproduce: 1. Drag and drop 4 rows from the source grid to the target grid. 2. Drag 1 more row from the source grid, and position the drop point either before the last row or after the last row. 3. Drop the row onto the target grid. 4. Watch the target grid drop feedback continue to display after the drop. Actual Results: The drop feedback on the target grid (grid border color and drop position indicator) continues to display after the drop is complete. Expected Results: The target grid's drop indicator should stop displaying after the drop is complete. Workaround (if any): None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FLEX-14658) Drop feedback still showing after call to hideDropFeedback
[ https://issues.apache.org/jira/browse/FLEX-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sébastien Kafif updated FLEX-14658: --- Attachment: DragDropFixed.mxml Here is a file to test the workaround Drop feedback still showing after call to hideDropFeedback -- Key: FLEX-14658 URL: https://issues.apache.org/jira/browse/FLEX-14658 Project: Apache Flex Issue Type: Bug Components: Drag and Drop Affects Versions: Adobe Flex SDK 3.0 (Release) Environment: Affected OS(s): Mac Affected OS(s): Mac OS 10.5 Browser: Firefox 2.x Language Found: English Reporter: Adobe JIRA Attachments: DragDropBugged.mxml, DragDropFixed.mxml These are the reproduction steps when running the application in the attached file: DragAndDropTest.mxml Steps to reproduce: 1. Drag and drop 4 rows from the source grid to the target grid. 2. Drag 1 more row from the source grid, and position the drop point either before the last row or after the last row. 3. Drop the row onto the target grid. 4. Watch the target grid drop feedback continue to display after the drop. Actual Results: The drop feedback on the target grid (grid border color and drop position indicator) continues to display after the drop is complete. Expected Results: The target grid's drop indicator should stop displaying after the drop is complete. Workaround (if any): None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [Marketing] - publicity
[1] http://www.theregister.co.uk/2013/01/14/adobe_flex_apache/ Om: I can talk to the editor. For the record, my response to where the project is would be: Thanks Om! I plan to arrange a call between you and Gavin. Will you please review the article he wrote and provide your complete contact information including: title, address, city, state, postal code, website, phone number and time zone? I will start a thread between you and Gavin making the introduction. Thanks! - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6047 - Release Date: 01/21/13
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Yeah, sounds great, we can start that way and get a quick lift-off, but in the long term, I would certainly also like contribute code to FalconJx. So as agreed above, I'll continue on my Wiki page. Concerning the tool chain / IDE, here is how we work with ActionScript / Jangaroo at CoreMedia: - Use Maven 3 for the build process: Jangaroo provides a Maven plugin to invoke the compiler and build library modules and complete applications - Use IntelliJ IDEA Ultimate (Community does not support AS) as IDE: We also wrote an IDEA plugin that plugs into IDEA's Maven import process, so when you import the Jangaroo Maven project, you can start right off. Our IDEA plugin also allows incremental compile and thus fast turn-around. - From Maven, you can easily fire up Jetty or Tomcat to serve and test the resulting web application. - We run unit tests through old FlexUnit 0.9, either in browser (using Selenium) or in PhantomJS. So besides PhantomJS, it is a pure Java solution, all you need installed is Maven and IDEA with Jangaroo plugin, and Maven takes care of downloading everything else (Jangaroo Maven plugin, Jangaroo compiler, Jangaroo libraries, ...). Because everything is deployed to Maven Central, you do not even need any special setup to use Jangaroo from Maven, and can start with very light-weight POMs. More about this in our quickstart example project: https://github.com/CoreMedia/jangaroo-quickstart With Apache Flex/FalconJx ready, I hope that IDEA will do all this out of the box. You would just choose a new Flash build configuration. Where currently you have target platforms Web (FlashPlayer plugin), mobile and desktop (both AIR flavors), there should be a new target Web (JavaScript/HTML5) (or the like). Flexmojos should take over the role of the Jangaroo Maven plugin. Hope this helps, -Frank- J8) On Mon, Jan 21, 2013 at 3:14 PM, Michael Schmalle apa...@teotigraphix.comwrote: Great! Here is my thought Frank, I see no reason for you to even have to write the AMD part. It dosn't make sense from a standpoint of time, when I get some other things out of the way, if I have a good spec it would take me less than a week with tests. This will allow you to focus on other things. BTW I wanted to ask, how does this now from your view fit into the tool chain IE IDEs, how do you work. Use IntelliJ for example. I'm curious because I have a WebAudio project I am going to be starting and I want to know how I would hook the compiler up to it's build system. Ideas? Mike Quoting Frank Wienberg fr...@jangaroo.net: On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle apa...@teotigraphix.com**wrote: Frank, Let me be direct, do you want to start working on AMD output? Not necessarily right now. Still seems like a steep learning curve for me. IMO you should definitely finish up the Wiki stuff so it clear what needs to be done with AMD output. I was straightly asking what helps you most, so if you say let's get the specification finished first, I'll continue with that ASAP! Cheers -Frank- J8) -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: Stage3D accelerated Flex components
Your blog post says uploads to GPU are slow, but I think that's incorrect (or at least incomplete). I think the bottle neck is the conversion from BitmapData to the texture format ( /texture.uploadFromBitmapData())/. If you use texture.uploadFromByteArray you'll see much faster throughputs. Which suggest, the bottleneck is not with stage3d and texture uploads generally, but with uploads from BitmapData (which is what the old display list produces). You may even be able to handle and cache some of that BMD - BGRA conversion yourself in MadComponents and gain a nice performance boost by using uploadFromByteArray() (at least when you can bypass redraw from the display list, which as I've said many times, is not well suited for a GPU workflow). More: http://jacksondunstan.com/articles/1617 Kevin N.
Re: [FalconJx] AMD-based JavaScript code implemented in Jangaroo
Yeah, thanks that makes the build process clear, What about the app development, debug from code to browser develop cycle? Like how do you envision the code being debugged, like how there is a Run/Debug and with breakpoints. This happens in the browser separate of the IDE? I have IntelliJ Ultimate, that is why I am asking about that in particular. Mike Quoting Frank Wienberg fr...@jangaroo.net: Yeah, sounds great, we can start that way and get a quick lift-off, but in the long term, I would certainly also like contribute code to FalconJx. So as agreed above, I'll continue on my Wiki page. Concerning the tool chain / IDE, here is how we work with ActionScript / Jangaroo at CoreMedia: - Use Maven 3 for the build process: Jangaroo provides a Maven plugin to invoke the compiler and build library modules and complete applications - Use IntelliJ IDEA Ultimate (Community does not support AS) as IDE: We also wrote an IDEA plugin that plugs into IDEA's Maven import process, so when you import the Jangaroo Maven project, you can start right off. Our IDEA plugin also allows incremental compile and thus fast turn-around. - From Maven, you can easily fire up Jetty or Tomcat to serve and test the resulting web application. - We run unit tests through old FlexUnit 0.9, either in browser (using Selenium) or in PhantomJS. So besides PhantomJS, it is a pure Java solution, all you need installed is Maven and IDEA with Jangaroo plugin, and Maven takes care of downloading everything else (Jangaroo Maven plugin, Jangaroo compiler, Jangaroo libraries, ...). Because everything is deployed to Maven Central, you do not even need any special setup to use Jangaroo from Maven, and can start with very light-weight POMs. More about this in our quickstart example project: https://github.com/CoreMedia/jangaroo-quickstart With Apache Flex/FalconJx ready, I hope that IDEA will do all this out of the box. You would just choose a new Flash build configuration. Where currently you have target platforms Web (FlashPlayer plugin), mobile and desktop (both AIR flavors), there should be a new target Web (JavaScript/HTML5) (or the like). Flexmojos should take over the role of the Jangaroo Maven plugin. Hope this helps, -Frank- J8) On Mon, Jan 21, 2013 at 3:14 PM, Michael Schmalle apa...@teotigraphix.comwrote: Great! Here is my thought Frank, I see no reason for you to even have to write the AMD part. It dosn't make sense from a standpoint of time, when I get some other things out of the way, if I have a good spec it would take me less than a week with tests. This will allow you to focus on other things. BTW I wanted to ask, how does this now from your view fit into the tool chain IE IDEs, how do you work. Use IntelliJ for example. I'm curious because I have a WebAudio project I am going to be starting and I want to know how I would hook the compiler up to it's build system. Ideas? Mike Quoting Frank Wienberg fr...@jangaroo.net: On Mon, Jan 21, 2013 at 1:55 PM, Michael Schmalle apa...@teotigraphix.com**wrote: Frank, Let me be direct, do you want to start working on AMD output? Not necessarily right now. Still seems like a steep learning curve for me. IMO you should definitely finish up the Wiki stuff so it clear what needs to be done with AMD output. I was straightly asking what helps you most, so if you say let's get the specification finished first, I'll continue with that ASAP! Cheers -Frank- J8) -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: Stage3D accelerated Flex components
Hi Kevin, I like to read your blog and learn a lot from the many interesting code optimisations. But i'm not so sure about your statements for this particular one: running your test a few times gives me different results: run 1: Driver,Test,Time,Bytes/Sec OpenGL,Texture from BitmapData w/o alpha,7,2396745.14 OpenGL,Texture from BitmapData w/ alpha,10,1677721.60 OpenGL,Texture from ByteArray,8,2097152.00 OpenGL,VertexBuffer from Vector,35,479341.71 OpenGL,VertexBuffer from ByteArray,3,5592320.00 OpenGL,IndexBuffer from Vector,2,1048574.00 OpenGL,IndexBuffer from ByteArray,1,2097148.00 Software Hw_disabled=explicit,Texture from BitmapData w/o alpha,9,1864135.11 Software Hw_disabled=explicit,Texture from BitmapData w/ alpha,4,4194304.00 Software Hw_disabled=explicit,Texture from ByteArray,4,4194304.00 Software Hw_disabled=explicit,VertexBuffer from Vector,12,1398080.00 Software Hw_disabled=explicit,VertexBuffer from ByteArray,5,3355392.00 Software Hw_disabled=explicit,IndexBuffer from Vector,1,2097148.00 Software Hw_disabled=explicit,IndexBuffer from ByteArray,1,2097148.00 run2: Driver,Test,Time,Bytes/Sec OpenGL,Texture from BitmapData w/o alpha,8,2097152.00 OpenGL,Texture from BitmapData w/ alpha,9,1864135.11 OpenGL,Texture from ByteArray,7,2396745.14 OpenGL,VertexBuffer from Vector,34,493440.00 OpenGL,VertexBuffer from ByteArray,3,5592320.00 OpenGL,IndexBuffer from Vector,2,1048574.00 OpenGL,IndexBuffer from ByteArray,1,2097148.00 Software Hw_disabled=explicit,Texture from BitmapData w/o alpha,9,1864135.11 Software Hw_disabled=explicit,Texture from BitmapData w/ alpha,4,4194304.00 Software Hw_disabled=explicit,Texture from ByteArray,5,3355443.20 Software Hw_disabled=explicit,VertexBuffer from Vector,12,1398080.00 Software Hw_disabled=explicit,VertexBuffer from ByteArray,4,4194240.00 Software Hw_disabled=explicit,IndexBuffer from Vector,1,2097148.00 Software Hw_disabled=explicit,IndexBuffer from ByteArray,1,2097148.00 run 3: Driver,Test,Time,Bytes/Sec OpenGL,Texture from BitmapData w/o alpha,6,2796202.67 OpenGL,Texture from BitmapData w/ alpha,9,1864135.11 OpenGL,Texture from ByteArray,8,2097152.00 OpenGL,VertexBuffer from Vector,33,508392.73 OpenGL,VertexBuffer from ByteArray,3,5592320.00 OpenGL,IndexBuffer from Vector,2,1048574.00 OpenGL,IndexBuffer from ByteArray,1,2097148.00 Software Hw_disabled=explicit,Texture from BitmapData w/o alpha,9,1864135.11 Software Hw_disabled=explicit,Texture from BitmapData w/ alpha,4,4194304.00 Software Hw_disabled=explicit,Texture from ByteArray,4,4194304.00 Software Hw_disabled=explicit,VertexBuffer from Vector,12,1398080.00 Software Hw_disabled=explicit,VertexBuffer from ByteArray,4,4194240.00 Software Hw_disabled=explicit,IndexBuffer from Vector,2,1048574.00 Software Hw_disabled=explicit,IndexBuffer from ByteArray,1,2097148.00 but for 2 of them (1 and 3) texture from bytearray is slower than texture from bitmapdata without alpha. is that because i'm on a mac? or maybe the flash player improved in the meantime? The article is a bit old :-) i'm on flash player 11.5 osx 10.8.2. Arnoud On 21-01-2013, at 20:54, Kevin Newman capta...@unfocus.com wrote: Your blog post says uploads to GPU are slow, but I think that's incorrect (or at least incomplete). I think the bottle neck is the conversion from BitmapData to the texture format ( /texture.uploadFromBitmapData())/. If you use texture.uploadFromByteArray you'll see much faster throughputs. Which suggest, the bottleneck is not with stage3d and texture uploads generally, but with uploads from BitmapData (which is what the old display list produces). You may even be able to handle and cache some of that BMD - BGRA conversion yourself in MadComponents and gain a nice performance boost by using uploadFromByteArray() (at least when you can bypass redraw from the display list, which as I've said many times, is not well suited for a GPU workflow). More: http://jacksondunstan.com/articles/1617 Kevin N. Met vriendelijke groet, Arnoud Bos Artim interactive E arn...@artim-interactive.nl W www.artim-interactive.nl T +31 6 246 40 216 A Elisabeth Wolffstraat 77-3 1053TT Amsterdam
[FalconJx] avoiding interesting merge situation ;-)
Mike, In the interest of expediency, will you be checking in a lot more today, or can I start to merge my local changes with your latest commits? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: Compiling MXMLs
You need to read the README. You need to have some environment variables
defined.
Carol
On 1/21/13 12 :40PM, Angelo Anolin angelo.ano...@gmail.com wrote:
Hi,
I haven't completely subscribed to the development of things so I need to
ask some few questions with regards to MXML compilations.
Previously (using Flex SDK 4.5), I compile my MXMLs like:
mxmlc -static-link-runtime-shared-libraries=false FILENAME.mxml
-output=\\MyOutputFolder -library-path+=MyComponent.swc
I just want to ask if what's the suggested way of compiling MXMLs through
the command line now?
I Just tried executing the above command line and I got the error:
Error: Unable to open '{playerglobalHome}/11.1/playerglobal.swc'
Current SDK I am using is
Version 4.90 Build 1425567
Appreciate your guidance.
Thank you.
Kind regards,
Angelo
[jira] [Commented] (FLEX-14658) Drop feedback still showing after call to hideDropFeedback
[ https://issues.apache.org/jira/browse/FLEX-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559101#comment-13559101 ] Carol Frampton commented on FLEX-14658: --- I just realized you are talking about Adobe Flex 3.0. You'll need to talk to Adobe about that version of Flex. The Flex 3 code base was not brought to Apache. If the bug still exists in Apache Flex 4.9 then you may get someone here interested in fixing it for a future version of Apache Flex. Drop feedback still showing after call to hideDropFeedback -- Key: FLEX-14658 URL: https://issues.apache.org/jira/browse/FLEX-14658 Project: Apache Flex Issue Type: Bug Components: Drag and Drop Affects Versions: Adobe Flex SDK 3.0 (Release) Environment: Affected OS(s): Mac Affected OS(s): Mac OS 10.5 Browser: Firefox 2.x Language Found: English Reporter: Adobe JIRA Attachments: DragDropBugged.mxml, DragDropFixed.mxml These are the reproduction steps when running the application in the attached file: DragAndDropTest.mxml Steps to reproduce: 1. Drag and drop 4 rows from the source grid to the target grid. 2. Drag 1 more row from the source grid, and position the drop point either before the last row or after the last row. 3. Drop the row onto the target grid. 4. Watch the target grid drop feedback continue to display after the drop. Actual Results: The drop feedback on the target grid (grid border color and drop position indicator) continues to display after the drop is complete. Expected Results: The target grid's drop indicator should stop displaying after the drop is complete. Workaround (if any): None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [FalconJx] avoiding interesting merge situation ;-)
I'm done, so do what you need to do, I promise I won't touch any files
in SVN until I see your new stuff.
I didn't change much that should affect you really. I haven't
committed the MXML specific api files yet, I'm waiting to get those
more concrete but things are working!
I have the ASBlcokWalker composited in the MXMLBlockWalker perfectly,
sharing the main GoogEmitter in the main walker. This design is
showing it's merit now!
So commit. I'm just going to work on the MXML stuff again. And yeah
that is your Main.mxml file that is cross compiled right now. ;-)
Mike
Quoting Erik de Bruin e...@ixsoftware.nl:
Ah, ping me when you're done for the day, so I'll know when it's safe
to figure out where my stuff goes in the new improved scheme :-)
EdB
On Mon, Jan 21, 2013 at 10:05 PM, Erik de Bruin e...@ixsoftware.nl wrote:
Awesome!
You go ahead, play for a while :-) Wouldn't want to break you out of
the zone. My changes can wait, I have other loose ends to tie up.
Have fun!
EdB
On Mon, Jan 21, 2013 at 10:03 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
Err...
DO it NOW! :) I am on a roll and at a point where it's safe, let me commit
one more tiny change.
Check this out. :)
goog.provide('Main');
goog.require('spark.components.Button');
goog.require('mx.events.FlexEvent');
/**
* @param {FlexEvent} event
*/
Main.prototype.creationCompleteHandler = function(event) {
var /** @type {Example} */ main = new Example();
this.addElement(main);
main.init();
}
It's fun playing in the sand!
Mike
Quoting Erik de Bruin e...@ixsoftware.nl:
Mike,
In the interest of expediency, will you be checking in a lot more
today, or can I start to merge my local changes with your latest
commits?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx] avoiding interesting merge situation ;-)
Erik, We seriously need to get a format.xml file to share for the Eclipse formater. Once we get passed this rough development we are only going to want to see non whitespace commits. I compulsively format all the time, it's habit. :) We can try to make it look a lot like falcons's maybe use Gordons if he has one, just need to get this figured out sooner than later. Mike -- Michael Schmalle - Teoti Graphix, LLC http://www.teotigraphix.com http://blog.teotigraphix.com
Re: [FalconJx] avoiding interesting merge situation ;-)
Ok, I've resolved a few minor conflicts and committed my code for
FalconJx. I completely agree on the formatter thing, the whitespace
stuff is already driving me nuts. I'll follow your lead.
I'll work on the publisher app a bit, but I must say, for a Monday,
things aren't going half bad. I have an AS project with a very simple
MXML to get AS access to spark components, and a 'large' AS file that
will show a button and a label, with a simple click event and handler,
all Flex SDK (spark).
The publisher app takes that AS project, runs it through FJx, runs the
resulting JS project through the 'goog' 'depswriter' script to get
only the library files actually used by the project, adds an
index.html from a template and enters the JS dependencies and then
launches the resulting HTML. So, with a bit of tweaking on my new JS
framework (VanillaSDK, couldn't resist ;-)) and maybe even some of
your MXML magic (no pressure!), in the coming days we should see
something that might open the door to the future of the Flex SDK with
web native playback.
Or I'll stumble upon a deal breaker; I'll give you even odds on that
happening :-)
EdB
On Mon, Jan 21, 2013 at 10:10 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
I'm done, so do what you need to do, I promise I won't touch any files in
SVN until I see your new stuff.
I didn't change much that should affect you really. I haven't committed the
MXML specific api files yet, I'm waiting to get those more concrete but
things are working!
I have the ASBlcokWalker composited in the MXMLBlockWalker perfectly,
sharing the main GoogEmitter in the main walker. This design is showing it's
merit now!
So commit. I'm just going to work on the MXML stuff again. And yeah that is
your Main.mxml file that is cross compiled right now. ;-)
Mike
Quoting Erik de Bruin e...@ixsoftware.nl:
Ah, ping me when you're done for the day, so I'll know when it's safe
to figure out where my stuff goes in the new improved scheme :-)
EdB
On Mon, Jan 21, 2013 at 10:05 PM, Erik de Bruin e...@ixsoftware.nl
wrote:
Awesome!
You go ahead, play for a while :-) Wouldn't want to break you out of
the zone. My changes can wait, I have other loose ends to tie up.
Have fun!
EdB
On Mon, Jan 21, 2013 at 10:03 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
Err...
DO it NOW! :) I am on a roll and at a point where it's safe, let me
commit
one more tiny change.
Check this out. :)
goog.provide('Main');
goog.require('spark.components.Button');
goog.require('mx.events.FlexEvent');
/**
* @param {FlexEvent} event
*/
Main.prototype.creationCompleteHandler = function(event) {
var /** @type {Example} */ main = new Example();
this.addElement(main);
main.init();
}
It's fun playing in the sand!
Mike
Quoting Erik de Bruin e...@ixsoftware.nl:
Mike,
In the interest of expediency, will you be checking in a lot more
today, or can I start to merge my local changes with your latest
commits?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: we need to better document the patch process
On Mon, Jan 21, 2013 at 7:05 AM, Carol Frampton cfram...@adobe.com wrote: Good morning, Ever time I go to apply a patch to take a look at the code, it has failed for various reasons. I took a quick look at our website and I didn't see anywhere obvious where we document how to generate a patch to attach to a JIRA bug. Did I overlook it? If so, we need to make it more obvious. If we haven't documented it we need to do that. I would suggest on the Source Code page we might want to nicely state that only commitors can commit to SVN, otherwise a patch needs to be added to a JIRA bug and then explain how to generate the patch. They should be created with svn and generated from root. Carol I am wondering if you are applying the patch in a wrong manner? ;-) For me (I use TortoiseSVN on Windows), no matter where in the hierarchy I try to apply the patch, I get notified that there is a better path to apply the patch - if there is one. I just accept the path that TortoiseSVN proposes and the patch is applied fine. What tools do you use and what kind of failures are you seeing? Thanks, Om
Adobe JIRA bug base
Hi, Just only noticed it myself but there's a notice on the Apache bug base that states: Starting in January 2013, the Flex and Flash Builder bug base will be available for read-only access. This system will be permanently retired in April 2013. Adobe plans to migrate the data to a static, public format for long-term archival and reference. Guess we can expect a little more JIRA traffic :-) Thanks, Justin
Re: [FalconJx] avoiding interesting merge situation ;-)
Quoting Erik de Bruin e...@ixsoftware.nl:
Ok, I've resolved a few minor conflicts and committed my code for
FalconJx. I completely agree on the formatter thing, the whitespace
stuff is already driving me nuts. I'll follow your lead.
I will get this together, I will set mine up to look as much like
Falcon does with it's formatting. Then we will just use the same one,
I wonder where we should put it... for other to be able to use if they
use Eclipse.
I'll work on the publisher app a bit, but I must say, for a Monday,
things aren't going half bad. I have an AS project with a very simple
MXML to get AS access to spark components, and a 'large' AS file that
will show a button and a label, with a simple click event and handler,
all Flex SDK (spark).
It's an interesting idea, and I never thought about trying to emulate
the Spark components in JavaScript. I will be interested how you do
with it.
The publisher app takes that AS project, runs it through FJx, runs the
resulting JS project through the 'goog' 'depswriter' script to get
only the library files actually used by the project, adds an
index.html from a template and enters the JS dependencies and then
launches the resulting HTML. So, with a bit of tweaking on my new JS
framework (VanillaSDK, couldn't resist ;-)) and maybe even some of
your MXML magic (no pressure!), in the coming days we should see
something that might open the door to the future of the Flex SDK with
web native playback.
Word, MXML is interesting because it is something but it can be
anything at the same time. It just depends on what you want it to be.
I'll tell you what is crazy, being in the visitDocument method and
getting all the Script blocks, looping through there IASNode array and
calling getWalker().walk(node) on each of them and it spits out goog
javascript right there in the MXML walker, pretty crazy. :)
Or I'll stumble upon a deal breaker; I'll give you even odds on that
happening :-)
Seems like there is innovative electricity in the air, never know
where it will take you.
Don't worry about the commit and merge, I will just add my stuff back,
it was my fault, I knew your were working on something and I
compulsively did the commits. :) Another reason using static utility
classes temporarily make sense sometimes.
Mike
EdB
On Mon, Jan 21, 2013 at 10:10 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
I'm done, so do what you need to do, I promise I won't touch any files in
SVN until I see your new stuff.
I didn't change much that should affect you really. I haven't committed the
MXML specific api files yet, I'm waiting to get those more concrete but
things are working!
I have the ASBlcokWalker composited in the MXMLBlockWalker perfectly,
sharing the main GoogEmitter in the main walker. This design is showing it's
merit now!
So commit. I'm just going to work on the MXML stuff again. And yeah that is
your Main.mxml file that is cross compiled right now. ;-)
Mike
Quoting Erik de Bruin e...@ixsoftware.nl:
Ah, ping me when you're done for the day, so I'll know when it's safe
to figure out where my stuff goes in the new improved scheme :-)
EdB
On Mon, Jan 21, 2013 at 10:05 PM, Erik de Bruin e...@ixsoftware.nl
wrote:
Awesome!
You go ahead, play for a while :-) Wouldn't want to break you out of
the zone. My changes can wait, I have other loose ends to tie up.
Have fun!
EdB
On Mon, Jan 21, 2013 at 10:03 PM, Michael Schmalle
apa...@teotigraphix.com wrote:
Err...
DO it NOW! :) I am on a roll and at a point where it's safe, let me
commit
one more tiny change.
Check this out. :)
goog.provide('Main');
goog.require('spark.components.Button');
goog.require('mx.events.FlexEvent');
/**
* @param {FlexEvent} event
*/
Main.prototype.creationCompleteHandler = function(event) {
var /** @type {Example} */ main = new Example();
this.addElement(main);
main.init();
}
It's fun playing in the sand!
Mike
Quoting Erik de Bruin e...@ixsoftware.nl:
Mike,
In the interest of expediency, will you be checking in a lot more
today, or can I start to merge my local changes with your latest
commits?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [Marketing] - publicity
On Mon, Jan 21, 2013 at 11:46 AM, Guthmann, Scott sguthm...@on3solutions.com wrote: [1] http://www.theregister.co.uk/2013/01/14/adobe_flex_apache/ Om: I can talk to the editor. For the record, my response to where the project is would be: Thanks Om! I plan to arrange a call between you and Gavin. Will you please review the article he wrote and provide your complete contact information including: title, address, city, state, postal code, website, phone number and time zone? I will start a thread between you and Gavin making the introduction. Thanks! Sounds good. I have sent my contact info to you via a pm. Thanks, Om
Re: we need to better document the patch process
On 1/21/13 5 :07PM, Om bigosma...@gmail.com wrote: On Mon, Jan 21, 2013 at 7:05 AM, Carol Frampton cfram...@adobe.com wrote: Good morning, Ever time I go to apply a patch to take a look at the code, it has failed for various reasons. I took a quick look at our website and I didn't see anywhere obvious where we document how to generate a patch to attach to a JIRA bug. Did I overlook it? If so, we need to make it more obvious. If we haven't documented it we need to do that. I would suggest on the Source Code page we might want to nicely state that only commitors can commit to SVN, otherwise a patch needs to be added to a JIRA bug and then explain how to generate the patch. They should be created with svn and generated from root. Carol I am wondering if you are applying the patch in a wrong manner? ;-) For me (I use TortoiseSVN on Windows), no matter where in the hierarchy I try to apply the patch, I get notified that there is a better path to apply the patch - if there is one. I just accept the path that TortoiseSVN proposes and the patch is applied fine. What tools do you use and what kind of failures are you seeing? I was using SmartSVN on OSX. The path was List.as. I tried from root and that failed so then I tried from the correct directory in Spark and that failed as well with a server error. Aside from that there is more than one List.as in the tree so the patch should really have the entire path, or at least more of the path to make it unique. Here is the patch: https://issues.apache.org/jira/secure/attachment/12565463/FLEX-33169_Mobile _List_Selection.patch Carol
Re: Adobe JIRA bug base
Interesting it is also for Flash Builder On Mon, Jan 21, 2013 at 5:09 PM, Justin Mclean jus...@classsoftware.comwrote: Hi, Just only noticed it myself but there's a notice on the Apache bug base that states: Starting in January 2013, the Flex and Flash Builder bug base will be available for read-only access. This system will be permanently retired in April 2013. Adobe plans to migrate the data to a static, public format for long-term archival and reference. Guess we can expect a little more JIRA traffic :-) Thanks, Justin
JIRA and closed and resolved bugs
Hi, We currently have a few bug that are resolved but not closed. https://issues.apache.org/jira/issues/?filter=12323441 As per the standard JIRA workflow to we want to move these bugs to closed once someone can confirm they work OR have both resolved and closed as meaning nothing further need to be done with this issue? The diagram here may be of some help: https://confluence.atlassian.com/display/JIRA/Configuring+Workflow Thanks, Justin
Re: we need to better document the patch process
On Mon, Jan 21, 2013 at 2:27 PM, Carol Frampton cfram...@adobe.com wrote: On 1/21/13 5 :07PM, Om bigosma...@gmail.com wrote: On Mon, Jan 21, 2013 at 7:05 AM, Carol Frampton cfram...@adobe.com wrote: Good morning, Ever time I go to apply a patch to take a look at the code, it has failed for various reasons. I took a quick look at our website and I didn't see anywhere obvious where we document how to generate a patch to attach to a JIRA bug. Did I overlook it? If so, we need to make it more obvious. If we haven't documented it we need to do that. I would suggest on the Source Code page we might want to nicely state that only commitors can commit to SVN, otherwise a patch needs to be added to a JIRA bug and then explain how to generate the patch. They should be created with svn and generated from root. Carol I am wondering if you are applying the patch in a wrong manner? ;-) For me (I use TortoiseSVN on Windows), no matter where in the hierarchy I try to apply the patch, I get notified that there is a better path to apply the patch - if there is one. I just accept the path that TortoiseSVN proposes and the patch is applied fine. What tools do you use and what kind of failures are you seeing? I was using SmartSVN on OSX. The path was List.as. I tried from root and that failed so then I tried from the correct directory in Spark and that failed as well with a server error. Aside from that there is more than one List.as in the tree so the patch should really have the entire path, or at least more of the path to make it unique. Here is the patch: https://issues.apache.org/jira/secure/attachment/12565463/FLEX-33169_Mobile _List_Selection.patch Carol Right, when I tried to apply that patch from root/sdk/, TortoiseSVN told me that there is a better path. I used that path, but the patch was rejected. It apparently found the wrong List.as. You are correct, this patch needs a better path to be applied. Thanks, Om
Re: Adobe JIRA bug base
Hi, Interesting it is also for Flash Builder You noticed that as well I wasn't going to point it out or people might jump to certain conclusions :-) Thanks, Justin
Re: Adobe JIRA bug base
Nothing particularly sinister going on here - we're just decomissioning JIRA in general. Fb bugs will in the future be filed via support/product team forums, and Flex bugs should be going to the Apache bugbase anyways. - Scott On 1/21/13 2:46 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Interesting it is also for Flash Builder You noticed that as well I wasn't going to point it out or people might jump to certain conclusions :-) Thanks, Justin
Adobe BlazeDS and 3.X SDK branch donation
Hi, Does anyone know if any progress has been made with the donation of these? Is there still anything else that Adobe was going to donate that's not showed up yet? Thanks, Justin
Re: Adobe JIRA bug base
Hi, Nothing particularly sinister going on here - we're just decomissioning JIRA in general. So in the near future there will be no public bug base for Flash Builder? and Flex bugs should be going to the Apache bugbase anyways. Flex bugs for Apache Flex 4.8 and 4.9 should be entered in Apache Flex bug base but not new Flex bugs for versions 3.X and 4.x of Adobe Flex (unless they effect both versions). Justin
Re: Adobe BlazeDS and 3.X SDK branch donation
On 1/21/13 2:51 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Does anyone know if any progress has been made with the donation of these? Is there still anything else that Adobe was going to donate that's not showed up yet? I think these are the last two on the 'promise' list. Squiggly will probably also get donated eventually. BlazeDS is being donated by a different team and I checked earlier in January and they said they have to clear up a legal issue. I don't have any details and haven't pressed them for it. 3.x could be a lot of work and nobody has asked for it recently, so it is on the back burner. There might be slightly easier ways to make it happen if we want to forgo SVN history, for example, but it is still a lot of work. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Adobe BlazeDS and 3.X SDK branch donation
Hi, BlazeDS is being donated by a different team and I checked earlier in January and they said they have to clear up a legal issue. I don't have any details and haven't pressed them for it. Mind asking what the legal issue is? 3.x could be a lot of work and nobody has asked for it recently, It just come up (indirectly) in a JIRA issue. https://issues.apache.org/jira/browse/FLEX-14658 There might be slightly easier ways to make it happen Most of us are external and only have a general idea to is required for this to happen inside Adobe at this point I think any shortcuts are worth investigating. Thanks, Justin
[jira] [Created] (FLEX-33361) [WEBSITE] Add Google Analytics tracking to flex.apache.org
OmPrakash Muppirala created FLEX-33361: -- Summary: [WEBSITE] Add Google Analytics tracking to flex.apache.org Key: FLEX-33361 URL: https://issues.apache.org/jira/browse/FLEX-33361 Project: Apache Flex Issue Type: Improvement Reporter: OmPrakash Muppirala Assignee: Nick Kwiatkowski Discussion here: http://markmail.org/message/dpmcb5hi5y7olwu2 Things to do: 1. Enable GA on flex.apache.org 2. Make stats available to Flex PMC 3. Share GA credentials to Flex PMC 4. Add a privacy-policy page to flex.apache.org a la http://jackrabbit.apache.org/privacy-policy.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Adobe BlazeDS and 3.X SDK branch donation
On 1/21/13 3:09 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, BlazeDS is being donated by a different team and I checked earlier in January and they said they have to clear up a legal issue. I don't have any details and haven't pressed them for it. Mind asking what the legal issue is? OK, I will ask. 3.x could be a lot of work and nobody has asked for it recently, It just come up (indirectly) in a JIRA issue. https://issues.apache.org/jira/browse/FLEX-14658 There might be slightly easier ways to make it happen Most of us are external and only have a general idea to is required for this to happen inside Adobe at this point I think any shortcuts are worth investigating. Personally, I would like to get the ASJS stuff to a certain point before spending time on 3.x donation. IMO, one bug in a year isn't enough to bump its priority. But if others jump on this thread wanting 3.x then I'll know it is worth diverting time to work on it -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Adobe BlazeDS and 3.X SDK branch donation
Hi, IMO, one bug in a year isn't enough to bump its priority. Agree but quite often things happen after stuff is donated not before. It was one of the then Adobe said they would donate it t's been a year. Given that amount of time has passed there probably is less demand for it but only because that amount of time has passed. I'm assuming from what you saying there very little work has been done on getting it into a donation ready state? Justin
Re: Apache Flex download statistics
Hi, I'm certainly not a lawyer but after thinking about the EU ePrivacy directive I though it would be enough to just have a privacy policy and explicitly state we use google analytics as we're only collecting anonymous data. There does seem to be a number of differing opinions out there regarding this. Thanks, Justin
Re: Adobe BlazeDS and 3.X SDK branch donation
On 1/21/13 4:55 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, IMO, one bug in a year isn't enough to bump its priority. Agree but quite often things happen after stuff is donated not before. It was one of the then Adobe said they would donate it t's been a year. Given that amount of time has passed there probably is less demand for it but only because that amount of time has passed. I'm assuming from what you saying there very little work has been done on getting it into a donation ready state? Yes. Did you think Carol and Peter and I had time to spare with the other set of donations, releases and graduation? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [VOTE] Allow tracking of download statistics on flex.apache.org
+1 (Binding), pending legal review from Apache. I don't see that being a show-stopper. -Nick On Mon, Jan 21, 2013 at 9:56 PM, Igor Costa igorco...@gmail.com wrote: +1 (Binding) Igor Costa www.igorcosta.com www.igorcosta.org On Mon, Jan 21, 2013 at 10:51 PM, Alex Harui aha...@adobe.com wrote: +1 (binding) On 1/21/13 4:49 PM, Om bigosma...@gmail.com wrote: Please vote to allow the use of Google Analytics [1] to track download statistics of Apache Flex source, binaries and Installer artifacts. If you have any comments, please reply in this thread: [2] Here is the JIRA ticket that describes what needs to be done [3] Thanks, Om [1] http://www.google.com/analytics/ [2] http://markmail.org/thread/g3l6t7gt2guxh7qg [3] https://issues.apache.org/jira/browse/FLEX-33361 -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [VOTE] Allow tracking of download statistics on flex.apache.org
+1 Sent from my mobile device. On Jan 21, 2013, at 6:49 PM, Om bigosma...@gmail.com wrote: Please vote to allow the use of Google Analytics [1] to track download statistics of Apache Flex source, binaries and Installer artifacts. If you have any comments, please reply in this thread: [2] Here is the JIRA ticket that describes what needs to be done [3] Thanks, Om [1] http://www.google.com/analytics/ [2] http://markmail.org/thread/g3l6t7gt2guxh7qg [3] https://issues.apache.org/jira/browse/FLEX-33361
Re: Adobe BlazeDS and 3.X SDK branch donation
On 1/21/13 6:40 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Yes. Did you think Carol and Peter and I had time to spare with the other set of donations, releases and graduation? Perhaps / perhaps not it has been a year I don't actually know. I asked because I have no visibility to how much work has been done on it nor do I know how much work is required to be done on it. Well, given the FalconJS donation landed in November and graduation and release started right around then, there hasn't been any spare time. Is it possible for the Flex committers or wider community to help with the donation in any way? Potentially. When I get back to dealing with the 3.x donation, one strategy is to only donate the few compiler changes, since the compiler code is under Adobe license. Apache owns most of the code already since some revision in SVN was the forking point for 4.x. Really, we only need permission to add any changes that were made to the 3.x branch that aren't already in the SVN because there were sync'ed to the mainline. In theory, but this needs legal approval so don't go off doing it now, all the ActionScript changes are under MPL, so any committer can move them. If we do it this way, we will lose SVN history at least in terms of chronology of changes, but the code will be there. There is also a branch of mustella for 3.x, but I think I would just run the current mustella tests against 3.x and see if that will suffice if we just exclude tests that fail. But again, I'm not motivated to move on it right away unless I see folks interested in it. Thanks, Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
On 1/21/13 5:21 PM, Om bigosma...@gmail.com wrote: On Fri, Jan 18, 2013 at 11:49 AM, Alex Harui aha...@adobe.com wrote: Changing subject because GPU rendering usually gets a lot of replies. In this new framework, I am trying to separate everything into little chunks I call beads. The visual components are supposed to have a minimum of three beads, one each for MVC, and the V is essentially the Skin. I spent some time going through your new framework. First off, I think it deserves to be called something else. The JS in ASJS implies that it is a JS specific implementation of the framework. In reality it is not. Well, I called that to show that it is a parallel framework. That we build both AS and JS beads. But I don't care to much about what we end up calling it. Second, it deserves its own wiki page. Well, I think there is one: https://cwiki.apache.org/confluence/display/FLEX/Alex%27s+FlexJS+Prototype The reason is: I see this as a clean way to start implementing a new Flex framework. The effort that you, Michael.S and Erik have undertaken to make it work in HTML/JS can work in parallel with a Starling/GPU based View for the same new Flex framework. Components don't assume they are on the Flash display list. Instead of calling addChild, you call child.addToParent. This makes a lot of sense. Except that Starling's APIs tries to mimic the current Flash Player's display list paradigm. I need to spend some time trying to figure out how I can tie these things up. Any thoughts? Did you see the thread today where someone else proposed an alternative to Starling? Starling may not be the best way to get at stage3D/gpu. Any emulation of the display list is likely to cost more cycles than one tuned to the platform. Do we really need a display list at all? If not, then don't use one. So, yes, you could write new view beads that create their visuals using starling. I suppose we could rewire addToParent to do what you want. This is the part that excites me most. I will start writing an implementation of your framework with a Starling based view. I might have to a new implementation of Application.as. In my view of the world, there will be many packages with different flavors of Applications, components and beads. Do you mind if I pollute the asjs directory with my code, or would you prefer that I do it on my whiteboard? I think you can do it directly in the asjs directory if you organize the packages in a reasonable way. I didn't explicitly design the new framework for starling. I think that is a good thing. The more clearer the separation there is between the rest of the framework and the render specific stuff, the better for everyone. I still need convincing that it truly makes a difference for the vast majority of business applications. I still think your Flex apps are busy running AS code or suffering from having too many display objects per component which I do want to tackle in this new framework. My take on this is: I have worked on so many data intensive applications where performance goes for a toss when the framework is trying to draw too many things on the screen. OK, but did you put in the profiler? Did [render] actually show up or is other code running instead? Utilizing the GPU (especially on mobile) would definitely make a difference. Again, do you have empirical evidence? It makes sense for sprite sheets in a game, but I don't understand what kind of visualization you are doing in your business apps that is similar. For legacy hardware, things would fallback to to a software engine anyways, so what is the harm in trying this out? No harm, if this is your itch, you are welcome to scratch it, but I am all about expectation management. So if it were me I would use profiler data to set expectations. One of my goals of the new framework is to try to apply simple principles of just-in-time and on-demand so the SDK doesn't waste cycles for just-in-case stuff like it does now. That alone might give you the performance boost you are looking for. The prototype is checked in: FalconJS is in the falcon/trunk/compiler.js folder. The latest ASJS framework is in asjs/branches/develop/framework, and the example that uses it is in asjs/branches/develop/examples/FlexJSTest_again. As I said earlier, it would be fantastic if you could split the new framework into separate directory and not throw it in along with ASJS. Does that make sense? Well, you can argue for a different name for the folder, but its ability to have a parallel JS framework is highly important and one of the major design/implementation constraints, so I like the idea there is an as folder next to the js folder in SVN. If your work turns out to be just alternative skins, that can be managed in a separate package or folder. For now, I think you should just start sticking in code and see what we end up with
Re: Adobe BlazeDS and 3.X SDK branch donation
HI, Yup, and so I will see how much interest this thread generates and use that to adjust my priorities. Users of the SDK may not be subscribed to developer list (or even the user list) so not really a way to gauge real world interest or need IMO. Justin
Re: Adobe BlazeDS and 3.X SDK branch donation
On 1/21/13 9:05 PM, Justin Mclean jus...@classsoftware.com wrote: HI, Yup, and so I will see how much interest this thread generates and use that to adjust my priorities. Users of the SDK may not be subscribed to developer list (or even the user list) so not really a way to gauge real world interest or need IMO. What would be your suggestion to get better data? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Adobe BlazeDS and 3.X SDK branch donation
Maybe with google trends http://www.google.fr/trends/explore#q=flex%203%2C%20flex%204%2C%20as3cmpt=q -Message d'origine- From: Alex Harui Sent: Tuesday, January 22, 2013 6:12 AM To: dev@flex.apache.org Subject: Re: Adobe BlazeDS and 3.X SDK branch donation On 1/21/13 9:05 PM, Justin Mclean jus...@classsoftware.com wrote: HI, Yup, and so I will see how much interest this thread generates and use that to adjust my priorities. Users of the SDK may not be subscribed to developer list (or even the user list) so not really a way to gauge real world interest or need IMO. What would be your suggestion to get better data? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Adobe BlazeDS and 3.X SDK branch donation
On 1/21/13 9:17 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Potentially. When I get back to dealing with the 3.x donation, one strategy is to only donate the few compiler changes Lost me there what compiler changes would be in the 3.x branch have that 4.X doesn't have? After we started 4.x, some bugs were fixed in 3.x only and vice versa. There were enough changes to 4.x compiler that 3.x patches wouldn't apply easily and vice-versa. Could we use the 4.X compiler to compile the 3.X SDK? Maybe, with compatibility mode on. I've never tried it, but I'd be surprised if it worked. In theory, but this needs legal approval so don't go off doing it now, all the ActionScript changes are under MPL, so any committer can move them. If all the AS files are under MPL why do they need legal sign off from Adobe? Apache has a policy of not taking open source code, even if compatibly licensed, without consent of the copyright owner. If we do it this way, we will lose SVN history at least in terms of chronology of changes, but the code will be there. I think most people would be fine with that. I guess we may need to run a vote at some point. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Adobe BlazeDS and 3.X SDK branch donation
Hi, Maybe with google trends http://www.google.fr/trends/explore#q=flex%203%2C%20flex%204%2C%20as3cmpt=q It shows interest in flex 3 at around 90% of that of flex 4 each month over the last 12 months. You get slightly different results if you use flex 3 and flex 4 so I'd say it's only rough indication but better than guessing. Justin
Re: [VOTE] Allow tracking of download statistics on flex.apache.org
On 1/21/13 5:49 PM, Om bigosma...@gmail.com wrote: Please vote to allow the use of Google Analytics [1] to track download statistics of Apache Flex source, binaries and Installer artifacts. If you have any comments, please reply in this thread: [2] Here is the JIRA ticket that describes what needs to be done [3] Thanks, Om [1] http://www.google.com/analytics/ [2] http://markmail.org/thread/g3l6t7gt2guxh7qg [3] https://issues.apache.org/jira/browse/FLEX-33361 +1 (binding)
Re: Adobe BlazeDS and 3.X SDK branch donation
1) Cannot upgrade to Flex 4.x As you stated somewhere and I've seen by myself migrating a big app to 4.8, it's better to stay in flex3 for big existing apps and use flex4 for new ones. 2) Can switch from Adobe Flex to Apache Flex The only reason I can see right now (there are probably some others) for people to not switching would be because the maven plugin migration wouldn't be straightforward, it would imply to mavenize the SDK and use it with FM6 3) Need a bug fixed in 3.x SDK that cannot be practically resolved via workaround or monkey-patch. Until now at work, they've been able to survive with that. What does it mean, IMO, big projects curently under Flex3 won't migrate to Flex4 and can survive with the last Flex3. -Fred -Message d'origine- From: Alex Harui Sent: Tuesday, January 22, 2013 6:50 AM To: dev@flex.apache.org Subject: Re: Adobe BlazeDS and 3.X SDK branch donation On 1/21/13 9:35 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Maybe with google trends http://www.google.fr/trends/explore#q=flex%203%2C%20flex%204%2C%20as3cmpt=q It shows interest in flex 3 at around 90% of that of flex 4 each month over the last 12 months. You get slightly different results if you use flex 3 and flex 4 so I'd say it's only rough indication but better than guessing. I'm not sure I understand. To me, the question isn't whether a lot of folks are using Flex 3. The question is: are there bugs in Flex 3 that they want fixed and if we fixed them they would/could use Apache Flex? IOW, you have to meet all of the following criteria: 1) Cannot upgrade to Flex 4.x 2) Can switch from Adobe Flex to Apache Flex 3) Need a bug fixed in 3.x SDK that cannot be practically resolved via workaround or monkey-patch. Otherwise, we'll spend all of this time on release candidates for 3.x without a significant payoff. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Adobe BlazeDS and 3.X SDK branch donation
Hi, 3) Need a bug fixed in 3.x SDK that cannot be practically resolved via workaround or monkey-patch. Until now at work, they've been able to survive with that. And you can run Adobe Flex 4.x like this as well (and I know project that do). Issue here is that the monkey patches remain in house and are not given back into the SDK for everyone to use. Justin
Re: JIRA and closed and resolved bugs
Hi, Still got the FLEX-33326 not closed because I still didn't test it thru the installer. -Fred -Message d'origine- From: Justin Mclean Sent: Monday, January 21, 2013 11:33 PM To: dev@flex.apache.org Subject: JIRA and closed and resolved bugs Hi, We currently have a few bug that are resolved but not closed. https://issues.apache.org/jira/issues/?filter=12323441 As per the standard JIRA workflow to we want to move these bugs to closed once someone can confirm they work OR have both resolved and closed as meaning nothing further need to be done with this issue? The diagram here may be of some help: https://confluence.atlassian.com/display/JIRA/Configuring+Workflow Thanks, Justin
Re: ASJS and Starling (was Re: [FalconJx] where I'm going to be)
Hi, I spent some time going through your new framework. First off, I think it deserves to be called something else. The JS in ASJS implies that it is a JS specific implementation of the framework. In reality it is not. Well, I called that to show that it is a parallel framework. That we build both AS and JS beads. But I don't care to much about what we end up calling it. Well, I do care. There are 2 naming conventions I think are working well right now: the intended use of a framework decides the first: ASJS stands for Actionscript to JavaScript, exactly what the frameworks and tools in there do. The second is the approach taken when going from AS to JS: first there is FlexJS, Alex's set of bottom up, start from scratch frameworks (one for AS and one for JS), and then there is VanillaSDK, my attempt at a top down, use the Flex SDK and write a complimentary JS framework approach. ASJS is also the home of the Publisher I'm writing, which will take either framework (FlexJS and VanillaSDK) and use it and it's dependencies to build an AS/MXML project into a HTML/JS project, again AS - JS. I don't mind renaming/rebranding things, especially is something is gained by doing so (even if it's only better marketing), but we should take care not to end up with a too generic naming convention just trying to fit too many projects under one roof. EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
