[jira] [Assigned] (FLEX-28946) MX DataGrid default column sort breaks on NULL complex fields
[
https://issues.apache.org/jira/browse/FLEX-28946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cyrill Zadra reassigned FLEX-28946:
---
Assignee: Cyrill Zadra
MX DataGrid default column sort breaks on NULL complex fields
-
Key: FLEX-28946
URL: https://issues.apache.org/jira/browse/FLEX-28946
Project: Apache Flex
Issue Type: Bug
Components: mx: DataGrid
Affects Versions: Adobe Flex SDK Previous
Environment: Affected OS(s): All OS Platforms
Affected OS(s): All OS Platforms
Language Found: English
Reporter: Adobe JIRA
Assignee: Cyrill Zadra
Labels: EasyFix
Attachments: FLEX-28946.patch
Steps to reproduce:
1.Create an mx:DataGrid with an ArrayCollection dataProvider populated with
Objects that have nested objects.
2.Set one of the properties of a nested object to null
3.Try sorting (by clicking on the header field) on a column that displays
that property (eg. address.city)
Actual Results:
TypeError: Error #1009: Cannot access a property or method of a null object
reference.
thrown in DataGridColumn.complexColumnSortCompare
the code does not check if resulting value is null
Note: DataGridColumn.deriveComplexColumnData function also does not check if
any component of complex property path is null
Expected Results:
Grid sorted on that column, nulls handled corretly (first in ascending order)
Workaround (if any):
Creating a custom compare function
Example MXML:
?xml version=1.0 encoding=utf-8?
s:Application xmlns:fx=http://ns.adobe.com/mxml/2009;
xmlns:s=library://ns.adobe.com/flex/spark
xmlns:mx=library://ns.adobe.com/flex/mx
minWidth=955 minHeight=600
fx:Script
![CDATA[
[Bindable]
public var data: Array = [
{name: Item1, address: {city: City1}},
{name: Item2, address: {city: null}},
];
]]
/fx:Script
fx:Declarations
/fx:Declarations
mx:DataGrid dataProvider={data}
mx:columns
mx:DataGridColumn headerText=Name dataField=name /
mx:DataGridColumn headerText=City
dataField=address.city /
/mx:columns
/mx:DataGrid
/s:Application
--
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: git commit: Removed files that do actually need to be edited and commited from time to time
Hi Justin, Again, I' woukd like to understand, why included thoses files in Git ? they weren't in Svn and from what I understand, the flex-sdk-description.xml and the bundles.properties are generated at compile time. Where am I wrong if I am ? Thanks, -Fred -Message d'origine- From: Frédéric THOMAS Sent: Saturday, March 23, 2013 1:27 PM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Ok, just because I see them as untracked and they're not in svn either. IIRC, they have been generated I might be wrong ? -Fred -Message d'origine- From: Justin Mclean Sent: Saturday, March 23, 2013 1:16 PM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, I didn't get that, those files are generated, why they shouldn't be ignored ? do they have to be committed ? They are not auto generated, can change and do need to be committed. Justin
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Alex, Does that [1] correspond better to what you described you wanted ? Thanks, -Fred [1] https://cwiki.apache.org/confluence/display/FLEX/Good+vs+Bad+Git+usage -Message d'origine- From: Alex Harui Sent: Sunday, March 24, 2013 5:39 AM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Guys, Sorry for writing in this late in your discussion. I really appreciate the time you both are putting into this. I finally got a chance to look at the wiki page. IMO, if you want to simplify, I think the first thing I would put on the wiki is the update the readme workflow. Most of us coming from SVN are not going to get the advantages of a branch right away and I think we've all agreed that it isn't always required. But after that, it seems like it would be better to explain the advantages of Git rather than trying to come up with a works most of the time solution that tries to make it so we don't have to learn key points about Git. I'd rather see links to the best example elsewhere on the net or short stories as to what rebase does, or why cutting a branch saved your ass, along with steps to do it and what those steps are doing. Git seems powerful enough that if you don't know what you are doing you can make a lot of work for yourself or others. And you can just link from this wiki to each of your own pages with your own workflows and commands instead of having to reach agreement. Just like there is some wiggle room in coding style it looks like there is some wiggle room in git style and, while that bugs me, I can live with it. I learned the finer aspects of writing code from several folks with different styles and I'm happy to learn the finer aspects of Git from several folks with different styles. If we all worked in the same room, I'd be asking Fred, how do you do this and Mike would overhear and offer his opinion and then I'd try one or both and learn something from it. On 3/23/13 5:38 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Okay, I have a long plane flight tomorrow I thought you had a cape !?#** :-) -Fred -Message d'origine- From: Michael A. Labriola Sent: Sunday, March 24, 2013 1:33 AM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Yes please. Okay, I have a long plane flight tomorrow. I will try to write something up so I can send it when I land. No problem, it just a talk, you and me want the best for Apache Flex. Thanks. Looking forward to figuring this out and helping everyone else get comfortable with git Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: git commit: Removed files that do actually need to be edited and commited from time to time
HI, Again, I' woukd like to understand, why included thoses files in Git ? Because they stopped me from checking in the locale changes I made the other day. Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Ok, then maybe we can find the solution somewhere else as it wasn't a problem for me, and once again, because those files are generated, they shouldn't go into Git, are we agree ? your solution to add them into Git seems a bit drastic to me, instead, could you add them again in the .gitignore and tell me what commands you did and what errors were displayed ? I might help on this. Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 8:34 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time HI, Again, I' woukd like to understand, why included thoses files in Git ? Because they stopped me from checking in the locale changes I made the other day. Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Hi, your solution to add them into Git seems a bit drastic to me, instead, could you add them again in the .gitignore and tell me what commands you did and what errors were displayed ? Files in question were auto generated by me (to same me typing) but are actually required if you want to do a release build so need to be in Git. They were not required if you just built for en_US. Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Well, It's where I don't understand though. If those files are generated during the build, they are also generated during the release, right ? Thanks for your time, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 8:52 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, your solution to add them into Git seems a bit drastic to me, instead, could you add them again in the .gitignore and tell me what commands you did and what errors were displayed ? Files in question were auto generated by me (to same me typing) but are actually required if you want to do a release build so need to be in Git. They were not required if you just built for en_US. Justin
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Hi Alex and Justin, when I came to the problem that I was to change 12 implementations I thought about it, but taking into account how other os products perform (Spring, Hibernate,...) over versions I thought that this kins of changes was possible since people should have a similar implementation and will be removing his method or overriding and extending. Other point was that we would expect few cases like this since in real apps people end making a removeItemAt(getItemIndex) thing at use case level, repeating code over and over. As I said if you try to upgrade from java os libraries like Hibernate, you will find you must to leverage a several change in your product that many times are not possible without invest many hours to finish the change, and people behind that product ends doing it due to always look forward. In this case, the change is not so big and we should expect not too much people having to make changes, but we could take this one to decide what philoshophy adopt in this cases. Options are: 1.- make a revert of all branch 2.- make a new Interface that extends the IList in the apache namespace with this method and make the 12 classes implement this new interface instead the old one. 3.- remove the new method from IList interface and left the new methods in the 12 classes. 4.- Make an utility class 5.- leave the change as it is more? Alex, you have the last word, but consider what other projects perform since you'll find that in the months coming some other changes will had to be crafted that will make some developers to make several changes if they want to upgrade. We can look forward to minimize this problem but in the end we must progress. For me additive changes like this should not be a problem and people should adapt to this one. In the end it was marked as easy fix. Please, let me know what to do and I will perform the change. 2013/3/25 Alex Harui aha...@adobe.com On 3/24/13 10:22 PM, Alex Harui aha...@adobe.com wrote: On 3/24/13 9:42 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, The fact he had to change all of those SDK files was a first clue that this could impact third-parties. Another possibility (possibly a little less useful but 100% 3rd party compatible) is to leave the interface as it was before (perhaps with the new method commented out to indicate it exists) and keep the new methods? And actually, your proposal is only 99.9% 3rd party compatible. There is a non-zero probability that someone implemented removeItem on a subclass of ListCollectionView or any of the other modified classes and this will bust them. That's a possibility, or create a utility class that implements that method. I doubt there is significant performance gains by implementing it over and over again in several places. Really, the documentation for that method should come with a warning that it does a linear search and that for large data sets, some other mechanism should be used to remove items. I don't write real applications like you folks do, but I would first make sure that I absolutely needed a method like this. For example, if you are deleting an object selected from a List, you already have the selectedIndex. Or if you know something about the data and its sort order, you can sometimes know to start at the end and work backwards. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
Re: git commit: Removed files that do actually need to be edited and commited from time to time
I think Justin is saying they are needed if you want to prepare a release build of the SDK (e.g. 4.9.5), not when you just build the SDK on your own machine. In this case I'd on the word of Justin and leave the files in git. EdB On Mon, Mar 25, 2013 at 8:58 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Well, It's where I don't understand though. If those files are generated during the build, they are also generated during the release, right ? Thanks for your time, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 8:52 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, your solution to add them into Git seems a bit drastic to me, instead, could you add them again in the .gitignore and tell me what commands you did and what errors were displayed ? Files in question were auto generated by me (to same me typing) but are actually required if you want to do a release build so need to be in Git. They were not required if you just built for en_US. Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Hi, I think in this case there's not going to be a lot of 3rd party code effected and it's easy enough to implement if someone want to use Apache Flex. If anyone has another opinion please speak up. Options are: 1.- make a revert of all branch 2.- make a new Interface that extends the IList in the apache namespace with this method and make the 12 classes implement this new interface instead the old one. 3.- remove the new method from IList interface and left the new methods in the 12 classes. 4.- Make an utility class 5.- leave the change as it is I'd learn towards option 2 or 3 or perhaps 4 or 5 but don't really have a strong opinion. I don't think we should revert. The performance is a non issue IMO - premature optimisation and all that. O(N) is fast unless N is very large and in some cases you wont know the index to remove so it's a useful addition. In the end it was marked as easy fix. That was me (I think) as I considered it something easy to do - just trying to encourage people :-) Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Well, sorry for the irritation you might have feel from my last post, happily, no files have been checked in by mistake yet. The point is almost none of us knows Git, even people who voted on and the decisions taken implying everybody without coordination at this early stage of the Git learning curve irritated me bit. Before a decision be taken, I guess we can ask the list if something looks weird or is not clear, even though the Apache Way is do it, we can go back later, I think at time it is good to ask before. Sorry again, -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 9:12 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time But, sorry, the official release build is not supposed to go into a release branch ? a personal release into a local release branch ? so, can't you custom the .gitignore in those branches instead of check in the develop branch files that shouldn't go in ? otherwise guys, why not check in *.swc, .zip and my grand mother photo at this point ? From once of those branch, you can easily turn back on the develop branch doing a git statsh -u my release untracked files before. Thanks, -Fred -Message d'origine- From: Erik de Bruin Sent: Monday, March 25, 2013 9:02 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time I think Justin is saying they are needed if you want to prepare a release build of the SDK (e.g. 4.9.5), not when you just build the SDK on your own machine. In this case I'd on the word of Justin and leave the files in git. EdB On Mon, Mar 25, 2013 at 8:58 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Well, It's where I don't understand though. If those files are generated during the build, they are also generated during the release, right ? Thanks for your time, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 8:52 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, your solution to add them into Git seems a bit drastic to me, instead, could you add them again in the .gitignore and tell me what commands you did and what errors were displayed ? Files in question were auto generated by me (to same me typing) but are actually required if you want to do a release build so need to be in Git. They were not required if you just built for en_US. Justin -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
I agree with your solution Carlos, I think that the fix should be in the IList itself, and not need create an alternative version. BTW, if it breaks the implementation of third parties will be a minor problem, and if you want to make an interface for compatibility, and call it IList2 as Alex said, it should be that did not contain the correction, so the people can implement this interface (to extinguish) or implement the new method. Best, -- Jose Barragan Chief Software Architect josebarra...@apache.org On Mar 25, 2013, at 9:01 AM, Carlos Rovira carlos.rov...@codeoscopic.com wrote: Hi Alex and Justin, when I came to the problem that I was to change 12 implementations I thought about it, but taking into account how other os products perform (Spring, Hibernate,...) over versions I thought that this kins of changes was possible since people should have a similar implementation and will be removing his method or overriding and extending. Other point was that we would expect few cases like this since in real apps people end making a removeItemAt(getItemIndex) thing at use case level, repeating code over and over. As I said if you try to upgrade from java os libraries like Hibernate, you will find you must to leverage a several change in your product that many times are not possible without invest many hours to finish the change, and people behind that product ends doing it due to always look forward. In this case, the change is not so big and we should expect not too much people having to make changes, but we could take this one to decide what philoshophy adopt in this cases. Options are: 1.- make a revert of all branch 2.- make a new Interface that extends the IList in the apache namespace with this method and make the 12 classes implement this new interface instead the old one. 3.- remove the new method from IList interface and left the new methods in the 12 classes. 4.- Make an utility class 5.- leave the change as it is more? Alex, you have the last word, but consider what other projects perform since you'll find that in the months coming some other changes will had to be crafted that will make some developers to make several changes if they want to upgrade. We can look forward to minimize this problem but in the end we must progress. For me additive changes like this should not be a problem and people should adapt to this one. In the end it was marked as easy fix. Please, let me know what to do and I will perform the change. 2013/3/25 Alex Harui aha...@adobe.com On 3/24/13 10:22 PM, Alex Harui aha...@adobe.com wrote: On 3/24/13 9:42 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, The fact he had to change all of those SDK files was a first clue that this could impact third-parties. Another possibility (possibly a little less useful but 100% 3rd party compatible) is to leave the interface as it was before (perhaps with the new method commented out to indicate it exists) and keep the new methods? And actually, your proposal is only 99.9% 3rd party compatible. There is a non-zero probability that someone implemented removeItem on a subclass of ListCollectionView or any of the other modified classes and this will bust them. That's a possibility, or create a utility class that implements that method. I doubt there is significant performance gains by implementing it over and over again in several places. Really, the documentation for that method should come with a warning that it does a linear search and that for large data sets, some other mechanism should be used to remove items. I don't write real applications like you folks do, but I would first make sure that I absolutely needed a method like this. For example, if you are deleting an object selected from a List, you already have the selectedIndex. Or if you know something about the data and its sort order, you can sometimes know to start at the end and work backwards. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Hi, If those files are generated during the build, they are also generated during the release, right ? Not all those files are auto generated and I think (not 100% sure of the top of my head) that some file names may be both auto generated and also need to be part of the release. Currently any Flex SDK release build or SDK with test run will currently will have file they you shouldn't check that are not in .gitignore but it may be hard to specify them as they are fairly generic eg Mustella results (txt, images and xml files) or properties files and xml config files. This wasn't an issue in SVN as there no need to check everything in. Thanks, Justin
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Hi Jose, as I think on it I'm more convinced that this is the way To make some parallelism, I remember changes like the added states in TextInputSkin from Flex 4.5 to 4.5.1 (I can't ensure the version) to support new prompt skin part. We get disabledStates (normalWithPrompts and disabledWithPrompt) and make all of us to rewrite our skins. A change that maybe was more aggressive, but was hide in the new minor version. This one is less aggressive since I'm sure that people making it's own IList implementation should be very few, against people using new removeItem that will be considerably bigger number. If people implementing must implement this method or should override and call parent, or replace for his own implementation, it's fine with me. As I state this is more about future phylosophy to adopt in forthcoming changes so maybe we should make a [Discuss] Thread? Again, I will make the needed changes although for me option 5 is the option. 2013/3/25 Jose Barragan jose.barra...@codeoscopic.com I agree with your solution Carlos, I think that the fix should be in the IList itself, and not need create an alternative version. BTW, if it breaks the implementation of third parties will be a minor problem, and if you want to make an interface for compatibility, and call it IList2 as Alex said, it should be that did not contain the correction, so the people can implement this interface (to extinguish) or implement the new method. Best, -- Jose Barragan Chief Software Architect josebarra...@apache.org On Mar 25, 2013, at 9:01 AM, Carlos Rovira carlos.rov...@codeoscopic.com wrote: Hi Alex and Justin, when I came to the problem that I was to change 12 implementations I thought about it, but taking into account how other os products perform (Spring, Hibernate,...) over versions I thought that this kins of changes was possible since people should have a similar implementation and will be removing his method or overriding and extending. Other point was that we would expect few cases like this since in real apps people end making a removeItemAt(getItemIndex) thing at use case level, repeating code over and over. As I said if you try to upgrade from java os libraries like Hibernate, you will find you must to leverage a several change in your product that many times are not possible without invest many hours to finish the change, and people behind that product ends doing it due to always look forward. In this case, the change is not so big and we should expect not too much people having to make changes, but we could take this one to decide what philoshophy adopt in this cases. Options are: 1.- make a revert of all branch 2.- make a new Interface that extends the IList in the apache namespace with this method and make the 12 classes implement this new interface instead the old one. 3.- remove the new method from IList interface and left the new methods in the 12 classes. 4.- Make an utility class 5.- leave the change as it is more? Alex, you have the last word, but consider what other projects perform since you'll find that in the months coming some other changes will had to be crafted that will make some developers to make several changes if they want to upgrade. We can look forward to minimize this problem but in the end we must progress. For me additive changes like this should not be a problem and people should adapt to this one. In the end it was marked as easy fix. Please, let me know what to do and I will perform the change. 2013/3/25 Alex Harui aha...@adobe.com On 3/24/13 10:22 PM, Alex Harui aha...@adobe.com wrote: On 3/24/13 9:42 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, The fact he had to change all of those SDK files was a first clue that this could impact third-parties. Another possibility (possibly a little less useful but 100% 3rd party compatible) is to leave the interface as it was before (perhaps with the new method commented out to indicate it exists) and keep the new methods? And actually, your proposal is only 99.9% 3rd party compatible. There is a non-zero probability that someone implemented removeItem on a subclass of ListCollectionView or any of the other modified classes and this will bust them. That's a possibility, or create a utility class that implements that method. I doubt there is significant performance gains by implementing it over and over again in several places. Really, the documentation for that method should come with a warning that it does a linear search and that for large data sets, some other mechanism should be used to remove items. I don't write real applications like you folks do, but I would first make sure that I absolutely needed a method like this. For example, if you are deleting an object selected from a List, you already have the
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Hi, But, sorry, the official release build is not supposed to go into a release branch ? No but the files needed to compile a release need to be :-) otherwise guys, why not check in *.swc, .zip and my grand mother photo at this point ? No swc or zips should be in Git but we might be able to get a photo of your grandmother into a mustella test :-) you can easily turn back on the develop branch doing a git statsh -u my release untracked files before. Given I might have a few hundred files scattered all over what would be the best way to do this? ie some I want to push but others I don't. Objvious only ones I commit will be pushed but I can't do a pull rebase in this state. Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Well, sure it's different than Svn. 1- The flex-sdk-descrition.xml and the bundle.properties are generated. 2- For the Mustella tests, as soon as I have the opportunity to run it, I'll fill the .gitignore in a almost complete generic way, I guess I can do it and propose it to this list as I did for the actual one. Actually, you can always use git stash -u MY MESSAGE before to checkout another branch, that save headaches :) Can I checkout and checkin the .gitignore as it was before, is that ok for you now ? Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 9:44 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, If those files are generated during the build, they are also generated during the release, right ? Not all those files are auto generated and I think (not 100% sure of the top of my head) that some file names may be both auto generated and also need to be part of the release. Currently any Flex SDK release build or SDK with test run will currently will have file they you shouldn't check that are not in .gitignore but it may be hard to specify them as they are fairly generic eg Mustella results (txt, images and xml files) or properties files and xml config files. This wasn't an issue in SVN as there no need to check everything in. Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Hi, Well, sorry for the irritation you might have feel from my last post, happily, no files have been checked in by mistake yet. No issue. I not checked any photos of my grandmother yet :-) The point is almost none of us knows Git, even people who voted on and the decisions taken implying everybody without coordination at this early stage of the Git learning curve irritated me bit. Couldn't agree with you more. Before a decision be taken Not sure any decision has been made here other than what was in .gitignore stop me from pushing files that are required to make a release build. We can modify .gitignore as required until everyone is happy with it. Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Ok, Can't we try to do a dummy release (or a real one as IIRC, one of the core lib hasn't been built correctly in the 2 last releases), so we could fill what is missing in the wiki and in the same time we could experiment Git for a release and fill a .gitignore ? Btw, because I didn't do any SDK release yet, I probably might miss things to understand your points, I want to sweep that. Well, that's a proposal that even if you approve it now will have to be delayed until the Installer has been released and I played with Mustella to update the .gitignore Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 9:51 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, But, sorry, the official release build is not supposed to go into a release branch ? No but the files needed to compile a release need to be :-) otherwise guys, why not check in *.swc, .zip and my grand mother photo at this point ? No swc or zips should be in Git but we might be able to get a photo of your grandmother into a mustella test :-) you can easily turn back on the develop branch doing a git statsh -u my release untracked files before. Given I might have a few hundred files scattered all over what would be the best way to do this? ie some I want to push but others I don't. Objvious only ones I commit will be pushed but I can't do a pull rebase in this state. Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
No issue. I not checked any photos of my grandmother yet :-) Ok, let's go forward so ;-) Not sure any decision has been made here other than what was in .gitignore stop me from pushing files that are required to make a release build. We can modify .gitignore as required until everyone is happy with it. I guess doing a release in a local branch should solve your untracked files problems, tell me if I'm wrong ? So, the one of the develop branch could be restored. Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 9:55 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, Well, sorry for the irritation you might have feel from my last post, happily, no files have been checked in by mistake yet. No issue. I not checked any photos of my grandmother yet :-) The point is almost none of us knows Git, even people who voted on and the decisions taken implying everybody without coordination at this early stage of the Git learning curve irritated me bit. Couldn't agree with you more. Before a decision be taken Not sure any decision has been made here other than what was in .gitignore stop me from pushing files that are required to make a release build. We can modify .gitignore as required until everyone is happy with it. Thanks, Justin
[jira] [Resolved] (FLEX-28946) MX DataGrid default column sort breaks on NULL complex fields
[
https://issues.apache.org/jira/browse/FLEX-28946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cyrill Zadra resolved FLEX-28946.
-
Resolution: Fixed
Fix Version/s: Apache Flex 4.10.0
commited patch to develop branch. mustella tests passes with no failure.
Thank you Mark for the contribution.
MX DataGrid default column sort breaks on NULL complex fields
-
Key: FLEX-28946
URL: https://issues.apache.org/jira/browse/FLEX-28946
Project: Apache Flex
Issue Type: Bug
Components: mx: DataGrid
Affects Versions: Adobe Flex SDK Previous
Environment: Affected OS(s): All OS Platforms
Affected OS(s): All OS Platforms
Language Found: English
Reporter: Adobe JIRA
Assignee: Cyrill Zadra
Labels: EasyFix
Fix For: Apache Flex 4.10.0
Attachments: FLEX-28946.patch
Steps to reproduce:
1.Create an mx:DataGrid with an ArrayCollection dataProvider populated with
Objects that have nested objects.
2.Set one of the properties of a nested object to null
3.Try sorting (by clicking on the header field) on a column that displays
that property (eg. address.city)
Actual Results:
TypeError: Error #1009: Cannot access a property or method of a null object
reference.
thrown in DataGridColumn.complexColumnSortCompare
the code does not check if resulting value is null
Note: DataGridColumn.deriveComplexColumnData function also does not check if
any component of complex property path is null
Expected Results:
Grid sorted on that column, nulls handled corretly (first in ascending order)
Workaround (if any):
Creating a custom compare function
Example MXML:
?xml version=1.0 encoding=utf-8?
s:Application xmlns:fx=http://ns.adobe.com/mxml/2009;
xmlns:s=library://ns.adobe.com/flex/spark
xmlns:mx=library://ns.adobe.com/flex/mx
minWidth=955 minHeight=600
fx:Script
![CDATA[
[Bindable]
public var data: Array = [
{name: Item1, address: {city: City1}},
{name: Item2, address: {city: null}},
];
]]
/fx:Script
fx:Declarations
/fx:Declarations
mx:DataGrid dataProvider={data}
mx:columns
mx:DataGridColumn headerText=Name dataField=name /
mx:DataGridColumn headerText=City
dataField=address.city /
/mx:columns
/mx:DataGrid
/s:Application
--
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: git commit: Removed files that do actually need to be edited and commited from time to time
HI, Just be aware that ant release is currently a little broken because of the move to Get (it assumes a SVN revision number). Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
True, so how do you sort that out at the moment ? -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 10:36 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time HI, Just be aware that ant release is currently a little broken because of the move to Get (it assumes a SVN revision number). Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
I had an issue running a release, it can't get http://java.net/projects/javacc/downloads/download/javacc-5.0.tar.gz error 443, how do I solve that ? -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 10:41 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time True, so how do you sort that out at the moment ? -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 10:36 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time HI, Just be aware that ant release is currently a little broken because of the move to Get (it assumes a SVN revision number). Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Sorry, the 443 came when I tried to get via my browser, the ant script returned Server returned HTTP response code: 500, I'll try later as it is an internal server error. -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 1:12 PM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time I had an issue running a release, it can't get http://java.net/projects/javacc/downloads/download/javacc-5.0.tar.gz error 443, how do I solve that ? -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 10:41 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time True, so how do you sort that out at the moment ? -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 10:36 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time HI, Just be aware that ant release is currently a little broken because of the move to Get (it assumes a SVN revision number). Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
HI, True, so how do you sort that out at the moment ? Just let it fail - it sets the release version to 0. Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Hi, I had an issue running a release, it can't get http://java.net/projects/javacc/downloads/download/javacc-5.0.tar.gz error 443, how do I solve that ? It's not the ant script getting that right? Sounds like you don't have a JDK installed? What does 'java -version and javac -version give you? Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
No, indeed I've got java installed, I can now access the web site but now the download, they say : We're sorry, but something went wrong. We've been notified about this issue and we'll take a look at it shortly I'll try later, thank you, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 1:24 PM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, I had an issue running a release, it can't get http://java.net/projects/javacc/downloads/download/javacc-5.0.tar.gz error 443, how do I solve that ? It's not the ant script getting that right? Sounds like you don't have a JDK installed? What does 'java -version and javac -version give you? Thanks, Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
Hi, No sure what your issue is - try this url: http://www.oracle.com/technetwork/java/javase/downloads/index.html You want JDK SE 7 or JDK SE 6. Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
I'm with the JDK 1.6.0_33 but that's ok, the server is running properly again. Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 1:32 PM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, No sure what your issue is - try this url: http://www.oracle.com/technetwork/java/javase/downloads/index.html You want JDK SE 7 or JDK SE 6. Justin
[Help] Native Drag and Drop in Apache Flex
Hi all, Is there any workaround to enable Native Drag and Drop feature in Apache Flex (Not in AIR)? -- * Regards, S. Jagan Langa*
Re: [Help] Native Drag and Drop in Apache Flex
If it is not in the hands of Apache, I have raised a feature request in Adobe site. Please vote for this. https://bugbase.adobe.com/index.cfm?event=bugid=3529257 On Mon, Mar 25, 2013 at 6:16 PM, Jagan Langa Sami Durai jaga...@sybrant.com wrote: Hi all, Is there any workaround to enable Native Drag and Drop feature in Apache Flex (Not in AIR)? -- * Regards, S. Jagan Langa* -- * Regards, S. Jagan Langa* *|* *Team Lead* *Sybrant Technologies Pvt Ltd* * * ‘Shriram The Gateway (SEZ)’, Block A1, 3rd Floor, 16 GST Road, Perungalathur, Chennai - 600 063, India India | USA | Germany | China Mobile: +91 98430 50897 Skype: seesamjagan
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
On 3/25/13 3:02 AM, Harbs harbs.li...@gmail.com wrote: I really don't see this as a really big deal. Even if someone implemented ILIst. The first time they try to compile, they will see a compile error that they didn't implement the new methods. All you really need to do is add a blank function. Are we worried about compiled libraries that the user does not have to source to? Is that a real concern? I've been told that some large companies have lots of legacy code they don't like to touch. That's why we did the Marshall Plan. Also, I am concerned that there are third-party libraries out there without anyone maintaining them (Parsley for example). I don't have any more final word than anyone else, I just want to make sure we think this is the right move. Breaking custom spark skins was one thing because there were fewer existing projects depending on it and those projects would be recent, but Ilist has been around for a long time. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
So Alex, what we do? revert? let the change live? make a Discuss thread so people could express the phylosophy with this issue and future similar tickets? Please, let us know so we can act accordingly Best Carlos 2013/3/25 Alex Harui aha...@adobe.com On 3/25/13 3:02 AM, Harbs harbs.li...@gmail.com wrote: I really don't see this as a really big deal. Even if someone implemented ILIst. The first time they try to compile, they will see a compile error that they didn't implement the new methods. All you really need to do is add a blank function. Are we worried about compiled libraries that the user does not have to source to? Is that a real concern? I've been told that some large companies have lots of legacy code they don't like to touch. That's why we did the Marshall Plan. Also, I am concerned that there are third-party libraries out there without anyone maintaining them (Parsley for example). I don't have any more final word than anyone else, I just want to make sure we think this is the right move. Breaking custom spark skins was one thing because there were fewer existing projects depending on it and those projects would be recent, but Ilist has been around for a long time. -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 94 80 80 http://www.codeoscopic.com http://www.directwriter.es http://www.avant2.es
Re: git commit: Removed files that do actually need to be edited and commited from time to time
IMO, Fred had it right. There are some files that go in the release distribution that we left sitting around in SVN, but they were in fact generated. Often folks would mistakenly edit the generated file and then wonder why their changes didn't take. I haven't researched bundles.properties, but I'm pretty sure: 1) flex-sdk-description.xml is autogenerated from a build.xml 2) spark/manifest.xml is copied from frameworks/spark-manifest.xml The latter burned me once when trying to add a new component to spark swc. On 3/25/13 12:58 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: Well, It's where I don't understand though. If those files are generated during the build, they are also generated during the release, right ? Thanks for your time, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 8:52 AM To: dev@flex.apache.org Subject: Re: git commit: Removed files that do actually need to be edited and commited from time to time Hi, your solution to add them into Git seems a bit drastic to me, instead, could you add them again in the .gitignore and tell me what commands you did and what errors were displayed ? Files in question were auto generated by me (to same me typing) but are actually required if you want to do a release build so need to be in Git. They were not required if you just built for en_US. Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
[jira] [Created] (FLEX-33450) RTE - PopupManager mx.controls.DataGrid
Bharath created FLEX-33450: -- Summary: RTE - PopupManager mx.controls.DataGrid Key: FLEX-33450 URL: https://issues.apache.org/jira/browse/FLEX-33450 Project: Apache Flex Issue Type: Bug Components: mx: DataGrid, PopUp Manager Affects Versions: Apache Flex 4.9.0, Adobe Flex SDK 4.5 (Release) Environment: Internet Explorer 8, Windows 7 Reporter: Bharath Priority: Blocker I'm getting a Runtime Exception on Internet Explorer [TypeError: Error #1009: Cannot access a property or method of a null object reference.] when using showing DataGrids on a TitleWindow using PopupManager. It works fine on FireFox. Unfortunately, all our users prefer Internet Explorer. 1) Open a TitleWindow from the main application.Two DataGrids are laid on a TitleWindow vertically. 2) Click into an editable column on the FIRST DataGrid and type something. 3) Move your mouse to another application (For eg., Outlook). 4) Now click into an editable column on the SECOND DataGrid. 5) The following exception is raised and the screen goes BLACK. TypeError: Error #1009: Cannot access a property or method of a null object reference. at mx.controls::DataGrid/itemEditorItemEditBeginHandler()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:5287] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/core/UIComponent.as:13160] at mx.controls::DataGrid/commitEditedItemPosition()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:4115] at mx.controls::DataGrid/updateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:1822] at mx.controls.listClasses::ListBase/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/listClasses/ListBase.as:3968] at mx.managers::LayoutManager/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:744] at mx.managers::LayoutManager/doPhasedInstantiation()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:827] at mx.managers::LayoutManager/doPhasedInstantiationCallback()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:1188] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick() -- 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: [1/4] git commit: add removeItem to IList and ListCollectionView
+1 on adding the method to IList... I have *lot* of code that look like
var index:int = list.getItemIndex(object);
if (index = 0) {
list.removeItemAt(index);
}
I think this is ugly and verbose, and it pollutes my function namespace - I
ends up with indexOfItemToRemove1 and some like this, as AS3 lacks
java-like block-level variables. Having static helper functions to mitigate
this kind of micro-issues is not ideal, as it makes the code less readable
and fluent, at least for my eyes.
I also think it is actually correct that existing methods are broken on
first compile: its a nice way for owners of that code to be aware of the
change, and thus look up if their custom method implementation can be
trashed or must be kept and renamed for some reason.
2013/3/25 Alex Harui aha...@adobe.com
On 3/25/13 8:00 AM, Carlos Rovira carlos.rov...@codeoscopic.com wrote:
So Alex,
what we do? revert? let the change live? make a Discuss thread so people
could express the phylosophy with this issue and future similar tickets?
Please, let us know so we can act accordingly
It is up to you. I have stated my concerns. There is no right or wrong
answer. If you are willing to take the time to start a discuss or poll,
feel free. So far, four people have voiced opinions and nobody thinks you
must revert.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
[jira] [Updated] (FLEX-33450) RTE - PopupManager mx.controls.DataGrid
[ https://issues.apache.org/jira/browse/FLEX-33450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath updated FLEX-33450: --- Attachment: TestPopup.fxp I'm attaching the test code here. RTE - PopupManager mx.controls.DataGrid --- Key: FLEX-33450 URL: https://issues.apache.org/jira/browse/FLEX-33450 Project: Apache Flex Issue Type: Bug Components: mx: DataGrid, PopUp Manager Affects Versions: Adobe Flex SDK 4.5 (Release), Apache Flex 4.9.0 Environment: Internet Explorer 8, Windows 7 Reporter: Bharath Priority: Blocker Attachments: TestPopup.fxp I'm getting a Runtime Exception on Internet Explorer [TypeError: Error #1009: Cannot access a property or method of a null object reference.] when using showing DataGrids on a TitleWindow using PopupManager. It works fine on FireFox. Unfortunately, all our users prefer Internet Explorer. 1) Open a TitleWindow from the main application.Two DataGrids are laid on a TitleWindow vertically. 2) Click into an editable column on the FIRST DataGrid and type something. 3) Move your mouse to another application (For eg., Outlook). 4) Now click into an editable column on the SECOND DataGrid. 5) The following exception is raised and the screen goes BLACK. TypeError: Error #1009: Cannot access a property or method of a null object reference. at mx.controls::DataGrid/itemEditorItemEditBeginHandler()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:5287] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/core/UIComponent.as:13160] at mx.controls::DataGrid/commitEditedItemPosition()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:4115] at mx.controls::DataGrid/updateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:1822] at mx.controls.listClasses::ListBase/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/listClasses/ListBase.as:3968] at mx.managers::LayoutManager/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:744] at mx.managers::LayoutManager/doPhasedInstantiation()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:827] at mx.managers::LayoutManager/doPhasedInstantiationCallback()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:1188] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick() -- 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-33450) RTE - PopupManager mx.controls.DataGrid
[ https://issues.apache.org/jira/browse/FLEX-33450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath updated FLEX-33450: --- Environment: Internet Explorer 8, Windows 7, FlashPlayer version [WIN 11,4,402,287] (was: Internet Explorer 8, Windows 7) RTE - PopupManager mx.controls.DataGrid --- Key: FLEX-33450 URL: https://issues.apache.org/jira/browse/FLEX-33450 Project: Apache Flex Issue Type: Bug Components: mx: DataGrid, PopUp Manager Affects Versions: Adobe Flex SDK 4.5 (Release), Apache Flex 4.9.0 Environment: Internet Explorer 8, Windows 7, FlashPlayer version [WIN 11,4,402,287] Reporter: Bharath Priority: Blocker Attachments: TestPopup.fxp I'm getting a Runtime Exception on Internet Explorer [TypeError: Error #1009: Cannot access a property or method of a null object reference.] when using showing DataGrids on a TitleWindow using PopupManager. It works fine on FireFox. Unfortunately, all our users prefer Internet Explorer. 1) Open a TitleWindow from the main application.Two DataGrids are laid on a TitleWindow vertically. 2) Click into an editable column on the FIRST DataGrid and type something. 3) Move your mouse to another application (For eg., Outlook). 4) Now click into an editable column on the SECOND DataGrid. 5) The following exception is raised and the screen goes BLACK. TypeError: Error #1009: Cannot access a property or method of a null object reference. at mx.controls::DataGrid/itemEditorItemEditBeginHandler()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:5287] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/core/UIComponent.as:13160] at mx.controls::DataGrid/commitEditedItemPosition()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:4115] at mx.controls::DataGrid/updateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:1822] at mx.controls.listClasses::ListBase/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/listClasses/ListBase.as:3968] at mx.managers::LayoutManager/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:744] at mx.managers::LayoutManager/doPhasedInstantiation()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:827] at mx.managers::LayoutManager/doPhasedInstantiationCallback()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:1188] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick() -- 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
[FalconJx] progress update
Hi, Just 'checking in': FalconJx can now compile the FlexJSTest_again example from the command line, using these arguments: +env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerGlobal/player +playerglobal.version=11.1 -load-config=/Applications/Adobe Flash Builder 4.7/sdks/4.9.1/frameworks/flex-config.xml -library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/libs/FlexJSUI.swc -js-output-type=FLEXJS -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js /Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/FlexJSTest_again/src/FlexJSTest.mxml Well, not exactly those, please change the paths to fit your local environment ;-) Next up: - support for publishing with the GCC and associated tricks (SourceMap etc.) - full FlexJS type AS - JS support (the current implementation is custom tailored to the FlexJSTest_Again example code) Have fun! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: [Git/Wiki] please review the proposed workflow and comment
I re-organized a bit to make it visually clearer but still, I guess it can be better and the text better written than with my words, I'm opened to see your suggestions. Okay, so, here is where we disagree. I do not think what you labeled as Bad is bad. It's not bad to me, it's an accurate depiction of what happened in git. The rebase on the other hand is rewriting history to make it seem linear when it *was not*. So, before saying we _want_ a linear history, let's discuss why. Mike
RE: [Git/Wiki] please review the proposed workflow and comment
I'm not sure what you mean talking about fork and repo, I might be wrong but that's more a GitHub concept to me but there's the concept of spare checkouts, it means, once you cloned the entirely repo, you can filter the directories you want to see which will make Git working easier, I mean with less memory. Fred, A fork is basically a server side clone. So, there is a server side repository belonging to the committers. We may not want to do this. I was asking if it had been discussed or considered rather than a branch approach for things like whiteboards. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Mike, Sure, it can be discussed. So, I think that what I write after you has to be written after what you write and my own experience with no-linear commit history tells me it shouldn't be done, it becomes quickly messy. Thanks, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 4:45 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I re-organized a bit to make it visually clearer but still, I guess it can be better and the text better written than with my words, I'm opened to see your suggestions. Okay, so, here is where we disagree. I do not think what you labeled as Bad is bad. It's not bad to me, it's an accurate depiction of what happened in git. The rebase on the other hand is rewriting history to make it seem linear when it *was not*. So, before saying we _want_ a linear history, let's discuss why. Mike
RE: [Git/Wiki] please review the proposed workflow and comment
So, I think that what I write after you has to be written after what you write and my own experience with no-linear commit history tells me it shouldn't be done, it becomes quickly messy. I am just going to go through each of your examples (which are very well done) and show my thoughts on each and why I think rebasing should be done extremely infrequently. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Mike, Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. AFAIK, it's technically possible to do it using git-svn to create users repo and then sharable bares repo (and there're maybe more direct ways to do it) but not possible from an existing git repo though. But what for new committers, should the INFRA create a new repo each time ? -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 4:47 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment I'm not sure what you mean talking about fork and repo, I might be wrong but that's more a GitHub concept to me but there's the concept of spare checkouts, it means, once you cloned the entirely repo, you can filter the directories you want to see which will make Git working easier, I mean with less memory. Fred, A fork is basically a server side clone. So, there is a server side repository belonging to the committers. We may not want to do this. I was asking if it had been discussed or considered rather than a branch approach for things like whiteboards. Mike
Re: [1/4] git commit: add removeItem to IList and ListCollectionView
Ok, as many people as stated they will prefer not revert, I will not make
any changes and will keep the IList removeItem new method and the method
implementations. I will postpone a Discussion thread for a later time when
we have more use cases that will make us to talk and discuss about global
philosophy.
Thanks all.
Carlos
2013/3/25 Cosma Colanicchia cosma...@gmail.com
+1 on adding the method to IList... I have *lot* of code that look like
var index:int = list.getItemIndex(object);
if (index = 0) {
list.removeItemAt(index);
}
I think this is ugly and verbose, and it pollutes my function namespace - I
ends up with indexOfItemToRemove1 and some like this, as AS3 lacks
java-like block-level variables. Having static helper functions to mitigate
this kind of micro-issues is not ideal, as it makes the code less readable
and fluent, at least for my eyes.
I also think it is actually correct that existing methods are broken on
first compile: its a nice way for owners of that code to be aware of the
change, and thus look up if their custom method implementation can be
trashed or must be kept and renamed for some reason.
2013/3/25 Alex Harui aha...@adobe.com
On 3/25/13 8:00 AM, Carlos Rovira carlos.rov...@codeoscopic.com
wrote:
So Alex,
what we do? revert? let the change live? make a Discuss thread so
people
could express the phylosophy with this issue and future similar
tickets?
Please, let us know so we can act accordingly
It is up to you. I have stated my concerns. There is no right or wrong
answer. If you are willing to take the time to start a discuss or poll,
feel free. So far, four people have voiced opinions and nobody thinks
you
must revert.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
RE: [Git/Wiki] please review the proposed workflow and comment
Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Mike, Btw, for what I'm about to do as described previously, I'll be happy if you can review and say your point of view / way to do it. Cheers, -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 6:14 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike
Re: [Git/Wiki] please review the proposed workflow and comment
Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [Git/Wiki] please review the proposed workflow and comment
I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. Ok, my next topic will be that showing up how it can be messy after only 3 commits. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? It might be simple to think that working on the develop branch makes flattened because only one commit at time and working on a branch create a parallel line which shows that merged branch. Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Actually, the Justin repo has this README at creation time, mine too, it's because it's not easily possible to keep an empty branch in Git, that's the reason why, but sure, I could have explained it. Thanks, -Fred -Message d'origine- From: Alex Harui Sent: Monday, March 25, 2013 6:40 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more complicated SVN. Just thinking aloud. Mike -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [Git/Wiki] please review the proposed workflow and comment
Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Arff, I don't like my last incomplete response, so the best way is that I'll have to create an other topic where I show how to create a bare shared repo and clones. -Fred -Message d'origine- From: Frédéric THOMAS Sent: Monday, March 25, 2013 6:53 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. Ok, my next topic will be that showing up how it can be messy after only 3 commits. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? It might be simple to think that working on the develop branch makes flattened because only one commit at time and working on a branch create a parallel line which shows that merged branch. Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Actually, the Justin repo has this README at creation time, mine too, it's because it's not easily possible to keep an empty branch in Git, that's the reason why, but sure, I could have explained it. Thanks, -Fred -Message d'origine- From: Alex Harui Sent: Monday, March 25, 2013 6:40 PM To: dev@flex.apache.org Subject: Re: [Git/Wiki] please review the proposed workflow and comment Hi Fred, I looked at your good/bad wiki page. Thanks for taking the time to add pictures. For me, instead of labeling things good and bad, it might be better to have an explanation or picture of the longer-term ramifications of each sequence and why one sequence is recommended. For example, I get that in the first scenario history gets flattened, but why does it really matter? And why, later, when you merge your branch, do you not want it flattened? Why will we all be glad some day that the history is flattened in certain cases but not others? Also, in the first scenario, it might be important to explain that you pushed your README change before Justin tried to push. You might need a two-column timeline to show what commands happened when. Thanks, -Alex On 3/25/13 10:14 AM, Frédéric THOMAS webdoubl...@hotmail.com wrote: To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner) Yes, that's meanly that, it will work except if people doesn't want to push right after the merge, in this rare case, it's better to use 'git rebase -p' instead of 'git pull --rebase', that's the only exception, almost of the time people will push as there are no reason to not do it, the 'git pull --rebase' method will be enough, people can trust it and it's simple to use, no headaches due to how git works inside, that's the reason why I wrote this workflow on the main git wiki page, I think it is adapted at what we do here. In a more general way, I want to show more examples like managing conflicts, git undo (reverse / reset / reflog undo / checkout), collaboration, etc... which are technical particularities but useful to know. In a more particular one, the workflow and the doc for the release. Thanks Mike, -Fred -Message d'origine- From: Michael A. Labriola Sent: Monday, March 25, 2013 5:43 PM To: dev@flex.apache.org Subject: RE: [Git/Wiki] please review the proposed workflow and comment Ok, so, yes, it has been discussed on this list with the conclusion it wasn't feasible by INFRA but one one asked them. Okay, that's fine if the people here decided it was infeasible I can accept that. Sometimes I think we just solve the wrong problems and I was wondering if that was the case here. To me, many of the reasons you are favoring the rebase workflow is so that people can't accidently mess up a merge (and yes, it can keep the history cleaner). Places like the Linux kernel don't have that issue because people are effectively working in their own repo with a limited number of people actually merging up into develop and managing master. It also makes the scenarios that I was describing to Alex, code reviewing someone's changes, jumping back and forth in time, all more feasible. Without it, we really do have everyone pushing their branches back into the same repo, etc. and it does feel (as several people have pointed out) like a more
[jira] [Updated] (FLEX-33450) RTE - PopupManager mx.controls.DataGrid
[ https://issues.apache.org/jira/browse/FLEX-33450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharath updated FLEX-33450: --- Description: I'm getting a Runtime Exception on Internet Explorer [TypeError: Error #1009: Cannot access a property or method of a null object reference.] when showing DataGrids on a TitleWindow using PopupManager. It works fine on FireFox. Unfortunately, all our users prefer Internet Explorer. 1) Open a TitleWindow from the main application.Two DataGrids are laid on a TitleWindow vertically. 2) Click into an editable column on the FIRST DataGrid and type something. 3) Move your mouse to another application (For eg., Outlook). 4) Now click into an editable column on the SECOND DataGrid. 5) The following exception is raised and the screen goes BLACK. TypeError: Error #1009: Cannot access a property or method of a null object reference. at mx.controls::DataGrid/itemEditorItemEditBeginHandler()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:5287] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/core/UIComponent.as:13160] at mx.controls::DataGrid/commitEditedItemPosition()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:4115] at mx.controls::DataGrid/updateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:1822] at mx.controls.listClasses::ListBase/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/listClasses/ListBase.as:3968] at mx.managers::LayoutManager/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:744] at mx.managers::LayoutManager/doPhasedInstantiation()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:827] at mx.managers::LayoutManager/doPhasedInstantiationCallback()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:1188] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick() was: I'm getting a Runtime Exception on Internet Explorer [TypeError: Error #1009: Cannot access a property or method of a null object reference.] when using showing DataGrids on a TitleWindow using PopupManager. It works fine on FireFox. Unfortunately, all our users prefer Internet Explorer. 1) Open a TitleWindow from the main application.Two DataGrids are laid on a TitleWindow vertically. 2) Click into an editable column on the FIRST DataGrid and type something. 3) Move your mouse to another application (For eg., Outlook). 4) Now click into an editable column on the SECOND DataGrid. 5) The following exception is raised and the screen goes BLACK. TypeError: Error #1009: Cannot access a property or method of a null object reference. at mx.controls::DataGrid/itemEditorItemEditBeginHandler()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:5287] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at mx.core::UIComponent/dispatchEvent()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/core/UIComponent.as:13160] at mx.controls::DataGrid/commitEditedItemPosition()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:4115] at mx.controls::DataGrid/updateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/DataGrid.as:1822] at mx.controls.listClasses::ListBase/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/mx/src/mx/controls/listClasses/ListBase.as:3968] at mx.managers::LayoutManager/validateDisplayList()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:744] at mx.managers::LayoutManager/doPhasedInstantiation()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:827] at mx.managers::LayoutManager/doPhasedInstantiationCallback()[/Users/justinmclean/Documents/ApacheFlexSDK/frameworks/projects/framework/src/mx/managers/LayoutManager.as:1188] at flash.utils::Timer/_timerDispatch() at flash.utils::Timer/tick() RTE - PopupManager mx.controls.DataGrid --- Key: FLEX-33450 URL:
Re: [FalconJx] progress update
Erik, I am planning to get FalconJX working on my machine soon. Before I start digging into it, 1. Are these wiki pages current? https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27+Way https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype 2. Do you have any thoughts on how we want to handle the resulting CSS? Inlining everything or have it as separate files? 3. My approach would take in a spark skin file and convert the fxg elements into svg+css. There is going to some AS code that needs to be converted JS. I believe your approach already handles this right? 4. I see that the VanillaSDK supports the Button component in HTML5. Maybe that is where I should start and get my code working there? Sorry if I am asking naive questions, but I am looking for some guidance on how to get my work integrated into FalconJx (or FalconJS) Thanks, Om On Mon, Mar 25, 2013 at 8:45 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Just 'checking in': FalconJx can now compile the FlexJSTest_again example from the command line, using these arguments: +env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerGlobal/player +playerglobal.version=11.1 -load-config=/Applications/Adobe Flash Builder 4.7/sdks/4.9.1/frameworks/flex-config.xml -library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/libs/FlexJSUI.swc -js-output-type=FLEXJS -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js /Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/FlexJSTest_again/src/FlexJSTest.mxml Well, not exactly those, please change the paths to fit your local environment ;-) Next up: - support for publishing with the GCC and associated tricks (SourceMap etc.) - full FlexJS type AS - JS support (the current implementation is custom tailored to the FlexJSTest_Again example code) Have fun! EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] progress update
Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. 4) Sounds like and excellent starting point... however, you'll probably have to tweak your local SDK 'a bit' to get both the Flex and JS side working. Or should be start one of those much rumored 'shared' feature branches of the SDK? I love how everything seems to be converging and it really feels like Flex - HTML5/JS is doable! EdB On Mon, Mar 25, 2013 at 7:21 PM, Om bigosma...@gmail.com wrote: Erik, I am planning to get FalconJX working on my machine soon. Before I start digging into it, 1. Are these wiki pages current? https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27+Way https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype 2. Do you have any thoughts on how we want to handle the resulting CSS? Inlining everything or have it as separate files? 3. My approach would take in a spark skin file and convert the fxg elements into svg+css. There is going to some AS code that needs to be converted JS. I believe your approach already handles this right? 4. I see that the VanillaSDK supports the Button component in HTML5. Maybe that is where I should start and get my code working there? Sorry if I am asking naive questions, but I am looking for some guidance on how to get my work integrated into FalconJx (or FalconJS) Thanks, Om On Mon, Mar 25, 2013 at 8:45 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Just 'checking in': FalconJx can now compile the FlexJSTest_again example from the command line, using these arguments: +env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerGlobal/player +playerglobal.version=11.1 -load-config=/Applications/Adobe Flash Builder 4.7/sdks/4.9.1/frameworks/flex-config.xml -library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/libs/FlexJSUI.swc -js-output-type=FLEXJS -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js /Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/FlexJSTest_again/src/FlexJSTest.mxml Well, not exactly those, please change the paths to fit your local environment ;-) Next up: - support for publishing with the GCC and associated tricks (SourceMap etc.) - full FlexJS type AS - JS support (the current implementation is custom tailored to the FlexJSTest_Again example code) Have fun! EdB -- 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
Re: [FalconJx] progress update
On Mon, Mar 25, 2013 at 11:55 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. Just to be clear, for all practical purposes, when I say FXG, I really mean MXML. This is because, the Flex implementation of FXG ensures that FXG elements can be pluggable inline into any MXML component. So, if we are to support MXML, then we must support FXG. In what I am doing currently, I am actually processing an MXML file, ignore things that I dont care about (like fx:Script, fx:Metadata, and any non-visual component) It just happens that for Spark components, the FXG elements appear only in their Spark skins. This makes my job easier because if I target only the spark skins, I wont have to deal with a lot of other MXML functional (i.e. non view) elements. 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. What if I want to handcode some javascript? For example, if I want to support the current 'states' paradigm used in spark skins, I need to write some javascript to make it a reusable component. I am not sure if this is the right approach, though. What do you guys think? 4) Sounds like and excellent starting point... however, you'll probably have to tweak your local SDK 'a bit' to get both the Flex and JS side working. Or should be start one of those much rumored 'shared' feature branches of the SDK? What kind of tweaking do you mean? Actually, I dont understand anything you just said. Please explain like I am 5 years old :-) I love how everything seems to be converging and it really feels like Flex - HTML5/JS is doable! Cautious optimism abounds! EdB On Mon, Mar 25, 2013 at 7:21 PM, Om bigosma...@gmail.com wrote: Erik, I am planning to get FalconJX working on my machine soon. Before I start digging into it, 1. Are these wiki pages current? https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27+Way https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype 2. Do you have any thoughts on how we want to handle the resulting CSS? Inlining everything or have it as separate files? 3. My approach would take in a spark skin file and convert the fxg elements into svg+css. There is going to some AS code that needs to be converted JS. I believe your approach already handles this right? 4. I see that the VanillaSDK supports the Button component in HTML5. Maybe that is where I should start and get my code working there? Sorry if I am asking naive questions, but I am looking for some guidance on how to get my work integrated into FalconJx (or FalconJS) Thanks, Om On Mon, Mar 25, 2013 at 8:45 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Just 'checking in': FalconJx can now compile the FlexJSTest_again example from the command line, using these arguments: +env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerGlobal/player +playerglobal.version=11.1 -load-config=/Applications/Adobe Flash Builder 4.7/sdks/4.9.1/frameworks/flex-config.xml -library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/libs/FlexJSUI.swc -js-output-type=FLEXJS -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js /Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/FlexJSTest_again/src/FlexJSTest.mxml Well, not exactly those, please change the paths to fit your local environment ;-) Next up: - support for publishing with the GCC and associated tricks (SourceMap etc.) - full FlexJS type AS - JS support (the current implementation is custom tailored to the FlexJSTest_Again example code) Have fun! EdB -- 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
Re: [FalconJx] progress update
On Mon, Mar 25, 2013 at 12:09 PM, Alex Harui aha...@adobe.com wrote: My answers in-line On 3/25/13 11:55 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. For FlexJS, I haven't decided on what to do. Currently, CSS is compiled into a datastream much like MXML is, but nothing on the JS side of FlexJS has required CSS yet, so essentially the problem is unsolved. I'm pretty sure we'll decide that we want one .css file that gets loaded in by the HTML wrapper. The compiler currently has the smarts that determines the right subset of the source CSS files (by culling out type-selectors that aren't used, for example). But knowing what your output will look like can certainly guide what we end up with. With my approach, to get the rendering fidelity to match that of Flex's skins, inline CSS makes it easy (because of the XSLT approach) BTW, we still need to deal with the 'cascading' part of CSS, right? One big .css file probably will not solve all questions. 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. 4) Sounds like and excellent starting point... however, you'll probably have to tweak your local SDK 'a bit' to get both the Flex and JS side working. Or should be start one of those much rumored 'shared' feature branches of the SDK? Peter and/or I plan to get started on the HTML5 set for FlexJS this week. You are welcome to wait or write that first Button yourself. BTW, what browser or runtime environment are you going to be working with? The button component is what I am using as my first use case. If things go well, I will have an independently working skinned HTML5 button component that can be plugged in anywhere. So far, everything I have done seems to be working with the latest versions of all major browsers. This means: Firefox 19.0.2 (Mac and Windows) Chrome 25.0.1 (Mac and Windows) IE 9 Safari (version unknown) Android Browser (Android version 4.1.2) iOS (version unknown) I prefer to not concentrate on older browsers because the Flash/Flex version of the same app should just work fine there. I love how everything seems to be converging and it really feels like Flex - HTML5/JS is doable! I finally got eclipse to build FalconJX from the Git sources. I'll be testing it out today. FalconJS had a few bugs that needed fixing and I'm hoping that you already fixed them in FalconJX. If not I'll fix them in FalconJX to help me learn that code. Hopefully there won't be any more code changes in compiler.js going forward. Are you saying that you are planning to switch to FalconJX soon? EdB On Mon, Mar 25, 2013 at 7:21 PM, Om bigosma...@gmail.com wrote: Erik, I am planning to get FalconJX working on my machine soon. Before I start digging into it, 1. Are these wiki pages current? https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27+Wa y https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype 2. Do you have any thoughts on how we want to handle the resulting CSS? Inlining everything or have it as separate files? 3. My approach would take in a spark skin file and convert the fxg elements into svg+css. There is going to some AS code that needs to be converted JS. I believe your approach already handles this right? 4. I see that the VanillaSDK supports the Button component in HTML5. Maybe that is where I should start and get my code working there? Sorry if I am asking naive questions, but I am looking for some guidance on how to get my work integrated into FalconJx (or FalconJS) Thanks, Om On Mon, Mar 25, 2013 at 8:45 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Just 'checking in': FalconJx can now compile the FlexJSTest_again example from the command line, using these arguments: +env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerG lobal/player +playerglobal.version=11.1 -load-config=/Applications/Adobe Flash Builder 4.7/sdks/4.9.1/frameworks/flex-config.xml -library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/ libs/FlexJSUI.swc -js-output-type=FLEXJS -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js
Re: [MENTORS] Voting on code donations
On Sun, Mar 24, 2013 at 10:14 AM, Alex Harui aha...@adobe.com wrote: Hi Former Mentors, We’ve had some generous offers of code donations. I noticed that some projects have votes about whether to accept code donations, but we haven’t for any Adobe donations to Apache Flex. Is voting optional? I think there is some ambiguity with regard to how donations are accepted. Honestly, I'm not an expert on these matters. I believe this page is the canonical source for how to handle donations: http://incubator.apache.org/ip-clearance/index.html Unfortunately, I've been covered up with family and work matters and really haven't been able to follow things as I should around here recently. Sorry about that. So I'm not familiar with the specific scenarios you are speaking of. But, generally, I can see the following scenarios: 1) An individual develops code and donates that to Apache. 2) An open-source project decides to donate code to an Apache project. 3) A private company donates code to a project. Scenario 1 is easy. If the individual is a committer, he/she can simply commit the code. If the individual is not a committer he/she can submit the code via a Jira patch or through the IP Clearance process (it's usually safer to use the IP Clearance process in this case). Scenario 3 is not too hard. The company has legal ownership of the code so the onus is on them to decide whether they have provenance to donate it. This is the most common use of the page I linked to above and it's how the Flex code came in from Adobe. Scenario 2 is more complicated. Contributions to the code may have come from different sources and all owners must agree to the donation. That can be tricky. The IP Clearance form linked from the page above contains a line item for the PMC voting to accept responsibility for the code. We didn't do that with the Adobe code because the Adobe donation was part of the proposal for the Incubating project. Note that the page says it's not for new projects. The vote to accept that code came when the Incubator PMC voted to accept the project into the Incubator. I think the best approach if we are talking about scenario 2 or scenario 1 with a non-committer is to hold a formal vote. Even if scenario 1 comes from a committer, holding a vote makes everything clear to anyone who may come along wondering later. Either way, I think a significant code donation from an external party works best if it goes through the IP Clearance process. It just makes sure everything is in order as it should be. If it's just a few files that a committer drew up on his/her own, then there's nothing wrong with committing the code to the repo and holding a simple vote. But anything more than that would be better done through the IP Clearance process. And a formal vote is implied, if not required, by that process. Hope that helps. Greg
Re: [FalconJx] progress update
Om, Just to be clear, for all practical purposes, when I say FXG, I really mean MXML. This is because, the Flex implementation of FXG ensures that FXG elements can be pluggable inline into any MXML component. So, if we are to support MXML, then we must support FXG. In what I am doing currently, I am actually processing an MXML file, ignore things that I dont care about (like fx:Script, fx:Metadata, and any non-visual component) It just happens that for Spark components, the FXG elements appear only in their Spark skins. This makes my job easier because if I target only the spark skins, I wont have to deal with a lot of other MXML functional (i.e. non view) elements. Currently, the way it's (going to be) set up is that when parsing MXML (which FalconJx now knows how to do), all script blocks and other non-MXML entities encountered along the way are parsed by their own type of parsers. So I imagine that you'd be writing a parser specifically for the FXG elements and that parser will be called when the MXML contains a FXG element. Would be my suggestion... 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. What if I want to handcode some javascript? For example, if I want to support the current 'states' paradigm used in spark skins, I need to write some javascript to make it a reusable component. I am not sure if this is the right approach, though. What do you guys think? All JS only, 'handcoded' scripts go in either the FlexJS and/or VanillaSDK JS frameworks (flex-asjs-frameworks-js), so I guess the FlexJS JS framework would be great place to put that for now (VanillaSDK is being held back a bit on account of me being only one person ;-). 4) Sounds like and excellent starting point... however, you'll probably have to tweak your local SDK 'a bit' to get both the Flex and JS side working. Or should be start one of those much rumored 'shared' feature branches of the SDK? What kind of tweaking do you mean? Actually, I dont understand anything you just said. Please explain like I am 5 years old :-) Well, VanillaSDK requires you to work with a modified Flex SDK and I don't have one ready to be shared just yet (hence the tweaking). Since Alex indicated FlexJS is nearly ready to handle your type of contribution, I think you best work with FlexJS for now. Cautious optimism abounds! Unbridled naiveté for the win :-P EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] progress update
Om, can you give an example? IMO, there is a difference between MXML Graphics and FXG. To me, FXG is stuff in an FXG file exported from several Adobe design tools. The internal pieces are not manipulated at run time. Today, FXG assets are compiled into Sprites and other SWF primitives. MXML Graphics in a skin are generally there for manipulation. The top-level tag is some component class. I think in FlexJS, I would suggest just writing components for Rect, Path, etc, so they can also be manipulated at runtime. On 3/25/13 12:15 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:55 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. Just to be clear, for all practical purposes, when I say FXG, I really mean MXML. This is because, the Flex implementation of FXG ensures that FXG elements can be pluggable inline into any MXML component. So, if we are to support MXML, then we must support FXG. In what I am doing currently, I am actually processing an MXML file, ignore things that I dont care about (like fx:Script, fx:Metadata, and any non-visual component) It just happens that for Spark components, the FXG elements appear only in their Spark skins. This makes my job easier because if I target only the spark skins, I wont have to deal with a lot of other MXML functional (i.e. non view) elements. 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. What if I want to handcode some javascript? For example, if I want to support the current 'states' paradigm used in spark skins, I need to write some javascript to make it a reusable component. I am not sure if this is the right approach, though. What do you guys think? 4) Sounds like and excellent starting point... however, you'll probably have to tweak your local SDK 'a bit' to get both the Flex and JS side working. Or should be start one of those much rumored 'shared' feature branches of the SDK? What kind of tweaking do you mean? Actually, I dont understand anything you just said. Please explain like I am 5 years old :-) I love how everything seems to be converging and it really feels like Flex - HTML5/JS is doable! Cautious optimism abounds! EdB On Mon, Mar 25, 2013 at 7:21 PM, Om bigosma...@gmail.com wrote: Erik, I am planning to get FalconJX working on my machine soon. Before I start digging into it, 1. Are these wiki pages current? https://cwiki.apache.org/confluence/display/FLEX/AS+to+JS+-+the+%27goog%27+Wa y https://cwiki.apache.org/confluence/display/FLEX/FalconJx+Prototype 2. Do you have any thoughts on how we want to handle the resulting CSS? Inlining everything or have it as separate files? 3. My approach would take in a spark skin file and convert the fxg elements into svg+css. There is going to some AS code that needs to be converted JS. I believe your approach already handles this right? 4. I see that the VanillaSDK supports the Button component in HTML5. Maybe that is where I should start and get my code working there? Sorry if I am asking naive questions, but I am looking for some guidance on how to get my work integrated into FalconJx (or FalconJS) Thanks, Om On Mon, Mar 25, 2013 at 8:45 AM, Erik de Bruin e...@ixsoftware.nl wrote: Hi, Just 'checking in': FalconJx can now compile the FlexJSTest_again example from the command line, using these arguments: +env.PLAYERGLOBAL_HOME=/Users/erik/Documents/ApacheFlex/dependencies/PlayerGl obal/player +playerglobal.version=11.1 -load-config=/Applications/Adobe Flash Builder 4.7/sdks/4.9.1/frameworks/flex-config.xml -library-path+=/Users/erik/Documents/ApacheFlex/git/flex-asjs/frameworks/as/l ibs/FlexJSUI.swc -js-output-type=FLEXJS -output=/Users/erik/Desktop/FlexJS/fromEclipse/FlexJSTest.js /Users/erik/Documents/ApacheFlex/git/flex-asjs/examples/FlexJSTest_again/src/ FlexJSTest.mxml Well, not exactly those, please change the paths to fit your local environment ;-) Next up: - support for publishing with the GCC and associated tricks (SourceMap etc.) - full FlexJS type AS - JS support (the current implementation is custom tailored to the FlexJSTest_Again example code) Have fun! EdB -- Ix Multimedia
[jira] [Commented] (FLEX-33350) CallOutButton for Web (desktop / not AIR)
[ https://issues.apache.org/jira/browse/FLEX-33350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13613025#comment-13613025 ] Maxime Cowez commented on FLEX-33350: - No companies involved. You have my blessing ;) CallOutButton for Web (desktop / not AIR) - Key: FLEX-33350 URL: https://issues.apache.org/jira/browse/FLEX-33350 Project: Apache Flex Issue Type: New Feature Components: .Unspecified - Framework Affects Versions: Apache Flex 4.9.0 Reporter: Marcus Fritze Assignee: Cyrill Zadra Fix For: Apache Flex 4.10.0 Attachments: CallOutButton.fxpl, CallOutButtonTest.fxp, CallOutButtonTest.zip, CallOutButton.zip based on the code provided by Maxime Cowez https://github.com/RIAstar/CallOutFx and the original CallOutButton (AIR version), I developed a CallOutButton for Web (desktop). Attachments: - CallOutButton (library project) - CallOutButtonTest (example project) Sorry, I am not a contributor and therefore I have no access to whiteboard for uploading an example. Maybe, if someone (a contributor) think this would be a nice component for Apache Flex, you can use it and upload it. Feedback is welcome! (Warning: there is a lot of commented-out source-code in the Callout.as) -- 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] progress update
Are you saying that you are planning to switch to FalconJX soon? Soon === Now That is... interesting :-) I guess it'll be a late night for me tonight. I have to set up the JS part of the FlexJS parsing. I've got the MXML in place, but the JS part will take me a bit of time. Are you up against a deadline somehow? EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
Re: [FalconJx] progress update
On 3/25/13 12:28 PM, Om bigosma...@gmail.com wrote: With my approach, to get the rendering fidelity to match that of Flex's skins, inline CSS makes it easy (because of the XSLT approach) BTW, we still need to deal with the 'cascading' part of CSS, right? Not quite sure what you mean, but for sure the AS side will eventually need a full CSS implementation. One big .css file probably will not solve all questions. By that, I meant gathering up the various CSS from the sources and libraries and concatenating them into one big file so you don't have to take several HTTP hits to get lots of small pieces. But if that's not a good thing, please explain why. I love how everything seems to be converging and it really feels like Flex - HTML5/JS is doable! I finally got eclipse to build FalconJX from the Git sources. I'll be testing it out today. FalconJS had a few bugs that needed fixing and I'm hoping that you already fixed them in FalconJX. If not I'll fix them in FalconJX to help me learn that code. Hopefully there won't be any more code changes in compiler.js going forward. Are you saying that you are planning to switch to FalconJX soon? Soon === Now -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
HI, Whatever the way to go, I'm not sure checkin empty.properties which are generated is the one. This are not auto generated but are required to compile the SDK for different locales - you need to do this in develop for testing or may actually want to compile the SDK for a locale other than en_US so I don't think these need to be in the release branch only. Also having a different set of files in release to develop is going to make merging difficult for starters. Justin
Re: [FalconJx] progress update
On 3/25/13 12:55 PM, Erik de Bruin e...@ixsoftware.nl wrote: Are you saying that you are planning to switch to FalconJX soon? Soon === Now That is... interesting :-) I guess it'll be a late night for me tonight. I have to set up the JS part of the FlexJS parsing. I've got the MXML in place, but the JS part will take me a bit of time. Are you up against a deadline somehow? Oh, I thought it was all there. Is it only MXML-AS? I am setting up my launch config now. What is FlexJS specific about the parsing? Or did you mean emitting? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
This are not auto generated They're copied from bundles/en_US/empty.properties to each locale at each build are required to compile the SDK for different locales - you need to do this in develop for testing or may actually want to compile the SDK for a locale other than en_US so I don't think these need to be in the release branch only are required to compile the SDK for different locales - you need to do this in develop for testing or may actually want to compile the SDK for a locale other than en_US so I don't think these need to be in the release branch only What I don't understand Justin, it's why they should go in Git so ? From what I understand, there's no needs. Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 10:09 PM To: dev@flex.apache.org Subject: Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works HI, Whatever the way to go, I'm not sure checkin empty.properties which are generated is the one. This are not auto generated but are required to compile the SDK for different locales - you need to do this in develop for testing or may actually want to compile the SDK for a locale other than en_US so I don't think these need to be in the release branch only. Also having a different set of files in release to develop is going to make merging difficult for starters. Justin
Re: git commit: Removed files that do actually need to be edited and commited from time to time
On 3/25/13 2:11 PM, Justin Mclean jus...@classsoftware.com wrote: HI, 1) flex-sdk-description.xml is autogenerated from a build.xml From the template file which needs to be in GIt. To me, the build.xml looks like it just echoes some text to the file. I don't see a template. 2) spark/manifest.xml is copied from frameworks/spark-manifest.xml So we need one in Git but not the other. I think I see frameworks/spark-manifest.xml under version control. Are you not seeing it? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
HI, They're copied from bundles/en_US/empty.properties to each locale at each build Only for the flash-integration target and this may or may not be the correct thing to do. It may of been a hack just to get it to work. At a future point locales may contain other translations. Also looks like the clean target may need a little work as well as it excluding all english locales. When creating a new locale via copylocale for any of the non en_US supported locales it the files need to exist in that locale and not copied from the en_US locale. eg copylocale en_AU en_NZ needs to work as this would be less work than copylocale en_US en_NZ. For this to work the files need to exist and be in GIt. Thanks, Justin
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
On 3/25/13 2:48 PM, Justin Mclean jus...@classsoftware.com wrote: HI, They're copied from bundles/en_US/empty.properties to each locale at each build Only for the flash-integration target and this may or may not be the correct thing to do. It may of been a hack just to get it to work. At a future point locales may contain other translations. Also looks like the clean target may need a little work as well as it excluding all english locales. When creating a new locale via copylocale for any of the non en_US supported locales it the files need to exist in that locale and not copied from the en_US locale. eg copylocale en_AU en_NZ needs to work as this would be less work than copylocale en_US en_NZ. For this to work the files need to exist and be in GIt. Could it be time to reconsider and make copylocale more tolerant of missing files? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
eg copylocale en_AU en_NZ needs to work as this would be less work than copylocale en_US en_NZ. For this to work the files need to exist and be in GIt Yes, but only the user use copylocale, not the build, right ? If so, when the user get the binaries, those files have been already generated and included inside or I'm wrong ? -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 10:48 PM To: dev@flex.apache.org Subject: Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works HI, They're copied from bundles/en_US/empty.properties to each locale at each build Only for the flash-integration target and this may or may not be the correct thing to do. It may of been a hack just to get it to work. At a future point locales may contain other translations. Also looks like the clean target may need a little work as well as it excluding all english locales. When creating a new locale via copylocale for any of the non en_US supported locales it the files need to exist in that locale and not copied from the en_US locale. eg copylocale en_AU en_NZ needs to work as this would be less work than copylocale en_US en_NZ. For this to work the files need to exist and be in GIt. Thanks, Justin
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
Hi, Could it be time to reconsider and make copylocale more tolerant of missing files? As I said this was an easier fix than changing the Java code inside copylcoale if you want to provide an alternative patch go ahead. Justin
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
Hi, Yes, but only the user use copylocale, not the build, right ? Well technically the build isn't broken (you can use it as a SDK and set different locales) but you may have trouble making a new locale form this build. I think it reasonable to assume that copylocale would work locales other than en_US. If so, when the user get the binaries, those files have been already generated and included inside or I'm wrong ? Nope some of the required files were missing which is why I added them. copylocale any non en_US locale new_locale would fail. Justin
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
Then, at this point why those files are not permanently in their corresponding locale directory rather than copied each time by the ant script ? it would allow them to stay in Git -Fred -Message d'origine- From: Justin Mclean Sent: Monday, March 25, 2013 11:09 PM To: dev@flex.apache.org Subject: Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works Hi, Yes, but only the user use copylocale, not the build, right ? Well technically the build isn't broken (you can use it as a SDK and set different locales) but you may have trouble making a new locale form this build. I think it reasonable to assume that copylocale would work locales other than en_US. If so, when the user get the binaries, those files have been already generated and included inside or I'm wrong ? Nope some of the required files were missing which is why I added them. copylocale any non en_US locale new_locale would fail. Justin
Re: [FalconJx] progress update
On Mon, Mar 25, 2013 at 12:26 PM, Alex Harui aha...@adobe.com wrote: Om, can you give an example? IMO, there is a difference between MXML Graphics and FXG. To me, FXG is stuff in an FXG file exported from several Adobe design tools. The internal pieces are not manipulated at run time. Today, FXG assets are compiled into Sprites and other SWF primitives. You are right, I am mixing my terms FXG and MXMLG when I speak. My workflow when working with FXG is more like this [1] Which really is just changing the namespace from FXG namespace to Spark namespace. Which is why the confusion, I guess. But to make it clear, I am less worried about about bringing FXG documents as graphic primitives into the HTML5/JS space. That would be nice, but not worth much. Here is a concrete example from \frameworks\projects\spark\src\spark\skins\spark\ButtonSkin.mxml snip !-- layer 1: shadow -- !--- @private -- s:Rect id=shadow left=-1 right=-1 top=-1 bottom=-1 radiusX=2 s:fill s:LinearGradient rotation=90 s:GradientEntry color=0x00 color.down=0xFF alpha=0.01 alpha.down=0 / s:GradientEntry color=0x00 color.down=0xFF alpha=0.07 alpha.down=0.5 / /s:LinearGradient /s:fill /s:Rect /snip This specifies an FXG Rect element with the attribute radiusX. So far so good. But the left, right, bottom and top are not part of the FXG spec [2] They are implemented as part of the ILayoutElement that one of the ancestors of s:Rect i.e. GraphicElement class. The way I am approaching is to make it a combination of SVG and CSS. This means that I can translate FXG's @radiusX into SVG's @rx. And I can translate MXMLG's @top into style=position:relative; top=-1 Is this the kind of example you wanted? I can go into more detail on my approach if you want. Let me know. Thanks, Om [1] http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8f26c150d412357de3591-8000.html#WSDAD87261-09E9-4091-8169-F2758607F125 [2] http://sourceforge.net/adobe/flexsdk/wiki/FXG%202.0%20Specification/ MXML Graphics in a skin are generally there for manipulation. The top-level tag is some component class. I think in FlexJS, I would suggest just writing components for Rect, Path, etc, so they can also be manipulated at runtime. On 3/25/13 12:15 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:55 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. Just to be clear, for all practical purposes, when I say FXG, I really mean MXML. This is because, the Flex implementation of FXG ensures that FXG elements can be pluggable inline into any MXML component. So, if we are to support MXML, then we must support FXG. In what I am doing currently, I am actually processing an MXML file, ignore things that I dont care about (like fx:Script, fx:Metadata, and any non-visual component) It just happens that for Spark components, the FXG elements appear only in their Spark skins. This makes my job easier because if I target only the spark skins, I wont have to deal with a lot of other MXML functional (i.e. non view) elements. 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. What if I want to handcode some javascript? For example, if I want to support the current 'states' paradigm used in spark skins, I need to write some javascript to make it a reusable component. I am not sure if this is the right approach, though. What do you guys think? 4) Sounds like and excellent starting point... however, you'll probably have to tweak your local SDK 'a bit' to get both the Flex and JS side working. Or should be start one of those much rumored 'shared' feature branches of the SDK? What kind of tweaking do you mean? Actually, I dont understand anything you just said. Please explain like I am 5 years old :-) I love how everything seems to be converging and it really feels like Flex - HTML5/JS is doable! Cautious optimism abounds! EdB
Re: [FalconJx] progress update
Hmm. But at the top-level is a non-FXG element like Skin or something like that, right? And, you don't know if script is going to change any of these entities at run-time. How are you going to make that happen when converted to SVG? Finally, nobody drew this skin in a design tool. It was hand-coded so it could have script code change things at runtime. IMO, a vector skinning model would leverage FXG as it is spec'd. Maybe we need to allow FXG in sub-documents in a skin (like we do for in-line item renderers with fx:Component), but I think you can also simply declare an FXG class as a tag in a skin. But from an MXML skin perspective, every tag maps to a class. On 3/25/13 3:18 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:26 PM, Alex Harui aha...@adobe.com wrote: Om, can you give an example? IMO, there is a difference between MXML Graphics and FXG. To me, FXG is stuff in an FXG file exported from several Adobe design tools. The internal pieces are not manipulated at run time. Today, FXG assets are compiled into Sprites and other SWF primitives. You are right, I am mixing my terms FXG and MXMLG when I speak. My workflow when working with FXG is more like this [1] Which really is just changing the namespace from FXG namespace to Spark namespace. Which is why the confusion, I guess. But to make it clear, I am less worried about about bringing FXG documents as graphic primitives into the HTML5/JS space. That would be nice, but not worth much. Here is a concrete example from \frameworks\projects\spark\src\spark\skins\spark\ButtonSkin.mxml snip !-- layer 1: shadow -- !--- @private -- s:Rect id=shadow left=-1 right=-1 top=-1 bottom=-1 radiusX=2 s:fill s:LinearGradient rotation=90 s:GradientEntry color=0x00 color.down=0xFF alpha=0.01 alpha.down=0 / s:GradientEntry color=0x00 color.down=0xFF alpha=0.07 alpha.down=0.5 / /s:LinearGradient /s:fill /s:Rect /snip This specifies an FXG Rect element with the attribute radiusX. So far so good. But the left, right, bottom and top are not part of the FXG spec [2] They are implemented as part of the ILayoutElement that one of the ancestors of s:Rect i.e. GraphicElement class. The way I am approaching is to make it a combination of SVG and CSS. This means that I can translate FXG's @radiusX into SVG's @rx. And I can translate MXMLG's @top into style=position:relative; top=-1 Is this the kind of example you wanted? I can go into more detail on my approach if you want. Let me know. Thanks, Om [1] http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8f26c150d412357de3591-8 000.html#WSDAD87261-09E9-4091-8169-F2758607F125 [2] http://sourceforge.net/adobe/flexsdk/wiki/FXG%202.0%20Specification/ MXML Graphics in a skin are generally there for manipulation. The top-level tag is some component class. I think in FlexJS, I would suggest just writing components for Rect, Path, etc, so they can also be manipulated at runtime. On 3/25/13 12:15 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:55 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. Just to be clear, for all practical purposes, when I say FXG, I really mean MXML. This is because, the Flex implementation of FXG ensures that FXG elements can be pluggable inline into any MXML component. So, if we are to support MXML, then we must support FXG. In what I am doing currently, I am actually processing an MXML file, ignore things that I dont care about (like fx:Script, fx:Metadata, and any non-visual component) It just happens that for Spark components, the FXG elements appear only in their Spark skins. This makes my job easier because if I target only the spark skins, I wont have to deal with a lot of other MXML functional (i.e. non view) elements. 3) Ah, there is the CSS, I guess (fxg - svg + css). The AS code will be cross-compiled to AS (weird, I know) or any form of JS we chose, most likely 'goog' JS, as it will have to be compatible with FlexJS and the VanillaSDK. Due to the way FalconJx is set up, it will be easy to add FXG specific JS parsing, if needed. What if I want to handcode some javascript? For
Re: [FalconJx] progress update
On Mon, Mar 25, 2013 at 3:25 PM, Alex Harui aha...@adobe.com wrote: Hmm. But at the top-level is a non-FXG element like Skin or something like that, right? I plan to use the div or svg elements for this. And, you don't know if script is going to change any of these entities at run-time. How are you going to make that happen when converted to SVG? You can manipulate div and svg using Javascript or CSS. I am working on an example of doing just this. Give me a couple of days to put out some sample code. Finally, nobody drew this skin in a design tool. It was hand-coded so it could have script code change things at runtime. Which is exactly why I want to transform the MXML/FXG code instead of relying on Illustrator spit out SVG for me. This way, we preserve all the custom skins that users might create for themselves directly in MXML. I am just relying on the fact that it resembles FXG which can be transformed into SVG relatively easily. IMO, a vector skinning model would leverage FXG as it is spec'd. Maybe we need to allow FXG in sub-documents in a skin (like we do for in-line item renderers with fx:Component), but I think you can also simply declare an FXG class as a tag in a skin. But from an MXML skin perspective, every tag maps to a class. Got it. I dont think it would take too much to support just pure FXG. In fact, that is what I started with. Now I am adding more Flex constructs on top of it. But the XSLT right now only supports the s: namespace. It shouldnt be hard to support the fxg namespace as well. Thanks, Om On 3/25/13 3:18 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:26 PM, Alex Harui aha...@adobe.com wrote: Om, can you give an example? IMO, there is a difference between MXML Graphics and FXG. To me, FXG is stuff in an FXG file exported from several Adobe design tools. The internal pieces are not manipulated at run time. Today, FXG assets are compiled into Sprites and other SWF primitives. You are right, I am mixing my terms FXG and MXMLG when I speak. My workflow when working with FXG is more like this [1] Which really is just changing the namespace from FXG namespace to Spark namespace. Which is why the confusion, I guess. But to make it clear, I am less worried about about bringing FXG documents as graphic primitives into the HTML5/JS space. That would be nice, but not worth much. Here is a concrete example from \frameworks\projects\spark\src\spark\skins\spark\ButtonSkin.mxml snip !-- layer 1: shadow -- !--- @private -- s:Rect id=shadow left=-1 right=-1 top=-1 bottom=-1 radiusX=2 s:fill s:LinearGradient rotation=90 s:GradientEntry color=0x00 color.down=0xFF alpha=0.01 alpha.down=0 / s:GradientEntry color=0x00 color.down=0xFF alpha=0.07 alpha.down=0.5 / /s:LinearGradient /s:fill /s:Rect /snip This specifies an FXG Rect element with the attribute radiusX. So far so good. But the left, right, bottom and top are not part of the FXG spec [2] They are implemented as part of the ILayoutElement that one of the ancestors of s:Rect i.e. GraphicElement class. The way I am approaching is to make it a combination of SVG and CSS. This means that I can translate FXG's @radiusX into SVG's @rx. And I can translate MXMLG's @top into style=position:relative; top=-1 Is this the kind of example you wanted? I can go into more detail on my approach if you want. Let me know. Thanks, Om [1] http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8f26c150d412357de3591-8 000.html#WSDAD87261-09E9-4091-8169-F2758607F125 [2] http://sourceforge.net/adobe/flexsdk/wiki/FXG%202.0%20Specification/ MXML Graphics in a skin are generally there for manipulation. The top-level tag is some component class. I think in FlexJS, I would suggest just writing components for Rect, Path, etc, so they can also be manipulated at runtime. On 3/25/13 12:15 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 11:55 AM, Erik de Bruin e...@ixsoftware.nl wrote: Om, 1) the wiki is mostly current, but as a work in progress: if it doesn't work, ask and we will fix ;-) 2) CSS resulting from...? I'm not familiar with FXG etc., so my questions are bound to be naive as well, as you'll notice. Basically we have access to whatever the compiler (Falcon-main, if you will) has access to, but some thing might be easier than others. Mike S. is our wizard, he'll know what to do if we can't figure it out. Just to be clear, for all practical purposes, when I say FXG, I really mean MXML. This
Re: [FalconJx] progress update
On 3/25/13 3:41 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 3:25 PM, Alex Harui aha...@adobe.com wrote: Hmm. But at the top-level is a non-FXG element like Skin or something like that, right? I plan to use the div or svg elements for this. Well, in FlexJS, we aren't translating MXML tags into HTML tags. The component API surface is the contract. You need to have wrapping code around the DOM elements in order to handle the abstraction. And, you don't know if script is going to change any of these entities at run-time. How are you going to make that happen when converted to SVG? You can manipulate div and svg using Javascript or CSS. See my note above. Again, you will need JS wrapping to abstract the differences. I am working on an example of doing just this. Give me a couple of days to put out some sample code. Finally, nobody drew this skin in a design tool. It was hand-coded so it could have script code change things at runtime. Which is exactly why I want to transform the MXML/FXG code instead of relying on Illustrator spit out SVG for me. This way, we preserve all the custom skins that users might create for themselves directly in MXML. I am just relying on the fact that it resembles FXG which can be transformed into SVG relatively easily. Well, if you want to re-use Spark skins, then FlexJS is not for you. FlexJS is a rewrite of Flex and the skinning model will likely be different because I want to try to fix the problems of Spark skins like the skin part contract, the extra display object, and the fact that most default skins had code in them. Over time, we can add enough alternative beads to fully mimic Spark Skins, but I really don't want to make that the default pattern for FlexJS. Erik thinks he can do all of this in VanillaJS. I still think it will take him too long to get to a minimal viable product and VanillaJS will have a huge minimal download and worry that folks are waiting for him instead of jumping in on FlexJS hoping he can provide the magic bullet. IMO, a vector skinning model would leverage FXG as it is spec'd. Maybe we need to allow FXG in sub-documents in a skin (like we do for in-line item renderers with fx:Component), but I think you can also simply declare an FXG class as a tag in a skin. But from an MXML skin perspective, every tag maps to a class. Got it. I dont think it would take too much to support just pure FXG. In fact, that is what I started with. Now I am adding more Flex constructs on top of it. But the XSLT right now only supports the s: namespace. It shouldnt be hard to support the fxg namespace as well. Thanks, Om On 3/25/13 3:18 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:26 PM, Alex Harui aha...@adobe.com wrote: Om, can you give an example? IMO, there is a difference between MXML Graphics and FXG. To me, FXG is stuff in an FXG file exported from several Adobe design tools. The internal pieces are not manipulated at run time. Today, FXG assets are compiled into Sprites and other SWF primitives. You are right, I am mixing my terms FXG and MXMLG when I speak. My workflow when working with FXG is more like this [1] Which really is just changing the namespace from FXG namespace to Spark namespace. Which is why the confusion, I guess. But to make it clear, I am less worried about about bringing FXG documents as graphic primitives into the HTML5/JS space. That would be nice, but not worth much. Here is a concrete example from \frameworks\projects\spark\src\spark\skins\spark\ButtonSkin.mxml snip !-- layer 1: shadow -- !--- @private -- s:Rect id=shadow left=-1 right=-1 top=-1 bottom=-1 radiusX=2 s:fill s:LinearGradient rotation=90 s:GradientEntry color=0x00 color.down=0xFF alpha=0.01 alpha.down=0 / s:GradientEntry color=0x00 color.down=0xFF alpha=0.07 alpha.down=0.5 / /s:LinearGradient /s:fill /s:Rect /snip This specifies an FXG Rect element with the attribute radiusX. So far so good. But the left, right, bottom and top are not part of the FXG spec [2] They are implemented as part of the ILayoutElement that one of the ancestors of s:Rect i.e. GraphicElement class. The way I am approaching is to make it a combination of SVG and CSS. This means that I can translate FXG's @radiusX into SVG's @rx. And I can translate MXMLG's @top into style=position:relative; top=-1 Is this the kind of example you wanted? I can go into more detail on my approach if you want. Let me know. Thanks, Om [1]
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
On 3/25/13 3:04 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Could it be time to reconsider and make copylocale more tolerant of missing files? As I said this was an easier fix than changing the Java code inside copylcoale if you want to provide an alternative patch go ahead. Yes, the change you made was simpler, but now you have to spend time dealing with the Git ramifications. Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
Just another point, I'm trying to build a release and the textLayout asdoc
target source-path point on ${source.dir}/src, it turns into an error,
shouldn't it be ${tlf.branch}/src ?
As reminder:
!-- Call asdoc to generate dita xml files --
asdoc output=${FLEX_HOME}/tempDoc lenient=true
failonerror=true keep-xml=true skip-xsl=true fork=true
compiler.source-path path-element=${source.dir}/src/
compiler.show-actionscript-warningsfalse/compiler.show-actionscript-warnings
doc-classes class=flashx.textLayout.CoreClasses/
doc-classes class=flashx.textLayout.EditClasses/
doc-classes class=flashx.textLayout.ConversionClasses/
doc-namespaces uri=library://ns.adobe.com/flashx/textLayout/
namespace uri=library://ns.adobe.com/flashx/textLayout
manifest=${source.dir}/manifest.xml/
jvmarg line=${asdoc.jvm.args}/
static-link-runtime-shared-libraries/
define name=CONFIG::debug value=${dbg}/
define name=CONFIG::release value=${rel}/
/asdoc
Thanks,
-Fred
-Message d'origine-
From: Alex Harui
Sent: Tuesday, March 26, 2013 1:04 AM
To: dev@flex.apache.org
Subject: Re: [1/3] Added misisng empty locales files for all supported
locales so that copylocale works
On 3/25/13 3:04 PM, Justin Mclean jus...@classsoftware.com wrote:
Hi,
Could it be time to reconsider and make copylocale more tolerant of
missing
files?
As I said this was an easier fix than changing the Java code inside
copylcoale
if you want to provide an alternative patch go ahead.
Yes, the change you made was simpler, but now you have to spend time dealing
with the Git ramifications.
Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
What would be the problem to do the opposite, check them in and not re-generate them ? Thanks, -Fred -Message d'origine- From: Justin Mclean Sent: Tuesday, March 26, 2013 1:35 AM To: dev@flex.apache.org Subject: Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works Hi, Yes, the change you made was simpler, but now you have to spend time dealing with the Git ramifications. Which is what exactly? That you have files that show up as changed in git status - easy don't check them in. We had exactly the same issue with SVN. Justin
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
Hi, What would be the problem to do the opposite, check them in and not re-generate them ? Currently the build is broken (themes are not compiling for some odd reason) so I'm unable to test. Justin
Re: [FalconJx] progress update
On Mar 25, 2013 5:04 PM, Alex Harui aha...@adobe.com wrote: On 3/25/13 3:41 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 3:25 PM, Alex Harui aha...@adobe.com wrote: Hmm. But at the top-level is a non-FXG element like Skin or something like that, right? I plan to use the div or svg elements for this. Well, in FlexJS, we aren't translating MXML tags into HTML tags. The component API surface is the contract. You need to have wrapping code around the DOM elements in order to handle the abstraction. Agreed. And, you don't know if script is going to change any of these entities at run-time. How are you going to make that happen when converted to SVG? You can manipulate div and svg using Javascript or CSS. See my note above. Again, you will need JS wrapping to abstract the differences. I think we can still handle that. I am working on an example of doing just this. Give me a couple of days to put out some sample code. Finally, nobody drew this skin in a design tool. It was hand-coded so it could have script code change things at runtime. Which is exactly why I want to transform the MXML/FXG code instead of relying on Illustrator spit out SVG for me. This way, we preserve all the custom skins that users might create for themselves directly in MXML. I am just relying on the fact that it resembles FXG which can be transformed into SVG relatively easily. Well, if you want to re-use Spark skins, then FlexJS is not for you. I don't want to reuse spark skins. I just want to use the spark paradigm for skinning. I am using the current spark skins as examples for the POC. FlexJS is a rewrite of Flex and the skinning model will likely be different because I want to try to fix the problems of Spark skins like the skin part contract, the extra display object, and the fact that most default skins had code in them. Over time, we can add enough alternative beads to fully mimic Spark Skins, but I really don't want to make that the default pattern for FlexJS. As long as we use MXMLG for the skins I would be happy. Do you still plan to use MXMLG in FlexJS? Erik thinks he can do all of this in VanillaJS. I still think it will take him too long to get to a minimal viable product and VanillaJS will have a huge minimal download and worry that folks are waiting for him instead of jumping in on FlexJS hoping he can provide the magic bullet. I would be happy to help out with FlexJS if I knew more about how you plan to implement skinning if components. Thanks, Om IMO, a vector skinning model would leverage FXG as it is spec'd. Maybe we need to allow FXG in sub-documents in a skin (like we do for in-line item renderers with fx:Component), but I think you can also simply declare an FXG class as a tag in a skin. But from an MXML skin perspective, every tag maps to a class. Got it. I dont think it would take too much to support just pure FXG. In fact, that is what I started with. Now I am adding more Flex constructs on top of it. But the XSLT right now only supports the s: namespace. It shouldnt be hard to support the fxg namespace as well. Thanks, Om On 3/25/13 3:18 PM, Om bigosma...@gmail.com wrote: On Mon, Mar 25, 2013 at 12:26 PM, Alex Harui aha...@adobe.com wrote: Om, can you give an example? IMO, there is a difference between MXML Graphics and FXG. To me, FXG is stuff in an FXG file exported from several Adobe design tools. The internal pieces are not manipulated at run time. Today, FXG assets are compiled into Sprites and other SWF primitives. You are right, I am mixing my terms FXG and MXMLG when I speak. My workflow when working with FXG is more like this [1] Which really is just changing the namespace from FXG namespace to Spark namespace. Which is why the confusion, I guess. But to make it clear, I am less worried about about bringing FXG documents as graphic primitives into the HTML5/JS space. That would be nice, but not worth much. Here is a concrete example from \frameworks\projects\spark\src\spark\skins\spark\ButtonSkin.mxml snip !-- layer 1: shadow -- !--- @private -- s:Rect id=shadow left=-1 right=-1 top=-1 bottom=-1 radiusX=2 s:fill s:LinearGradient rotation=90 s:GradientEntry color=0x00 color.down=0xFF alpha=0.01 alpha.down=0 / s:GradientEntry color=0x00 color.down=0xFF alpha=0.07 alpha.down=0.5 / /s:LinearGradient /s:fill /s:Rect /snip This specifies an FXG Rect element with the attribute radiusX. So far so good. But the left, right, bottom and
Re: [FalconJx] progress update
Well, first off, thanks for motivating me to spend more time thinking about skinning. Honestly, I don't have a formal plan and your input is quite welcome. I spent a fair amount of time mulling over how to re-use as much of existing spark skins as possible and how to leverage your FXG-SVG work. On 3/25/13 6:28 PM, Om bigosma...@gmail.com wrote: Well, if you want to re-use Spark skins, then FlexJS is not for you. I don't want to reuse spark skins. I just want to use the spark paradigm for skinning. I am using the current spark skins as examples for the POC. I'm not sure what it means if you don't want to reuse spark skins but want to use the spark paradigm. What are the key pieces? FlexJS is a rewrite of Flex and the skinning model will likely be different because I want to try to fix the problems of Spark skins like the skin part contract, the extra display object, and the fact that most default skins had code in them. Over time, we can add enough alternative beads to fully mimic Spark Skins, but I really don't want to make that the default pattern for FlexJS. As long as we use MXMLG for the skins I would be happy. Do you still plan to use MXMLG in FlexJS? I hadn't given it much thought. At minimum, we could create components like Rect, Line, Path like we have for Button, CheckBox and Label. They would inject SVG into the DOM as appropriate. But in thinking more about it, your transform of MXMLG or FXG to SVG is essentially an optimization. The reason I say that is because, if you start from SparkSkin, you have the problem that in more complex components, the skin is not pure MXMLG/FXG, it is comprised of other top-level components. It is only in cases where you have an uninterrupted stream of graphics that you can apply this transform. I guess we could make the compiler that smart, but that sounds like advanced work. One way I think about developing FlexJS is that we are trying to identify the smallest, most self-contained, best practice for doing things in HTML (whether it is skinning, drag-drop, effects) and then designing an ActionScript equivalent for it, and then tweaking both sides to make it more Flex-like. At least for now, that is the most efficient way to get more components up and running faster because there is less mucking around in JS trying to get it to do something that was easy in Flash. So, I need to research more about how skinning works in HTML5, but I have this vague recollection that skins in HTML5 are entirely graphics. IOW, a complex component comprised of subcomponents doesn't have a skin that describes those sub-components like Spark does. Instead, the set of sub-components is fixed and you can alter the visuals of those sub-components via CSS. For example, you use advanced CSS selectors to set the visuals for a Button in a ComboBox. I also need to understand how an HTML5 button skin changes its visuals with hover/down/selected/focused/emphasized. That would also educate how we set up a skinning model for FlexJS. And something like that is more in tune with FlexJS. Today, the AS components have a view bead that determines the subcomponents. Those subcomponents have their own view beads. The leaves of that tree of view beads is entirely graphics (today in AS, next stop for me was bitmaps, you are welcome to take on MXML or FXG or some vector description). Someday, I'll get enough CSS working so that you can set the view beads at the leaves of the tree, and then we can say that you can define those view beads entirely in graphics with certain restrictions, like no sub-components. Maybe we'll give that a separate file suffix, then the compiler can know to run your transform on it. Thoughts on that? -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
On 3/25/13 5:28 PM, Frédéric THOMAS webdoubl...@hotmail.com wrote:
Just another point, I'm trying to build a release and the textLayout asdoc
target source-path point on ${source.dir}/src, it turns into an error,
shouldn't it be ${tlf.branch}/src ?
Ah yes, I never did finish the release target. I just got main and
checkintests to run. If you can fix it, great, if not, I will try to get to
it later in the week.
As reminder:
!-- Call asdoc to generate dita xml files --
asdoc output=${FLEX_HOME}/tempDoc lenient=true
failonerror=true keep-xml=true skip-xsl=true fork=true
compiler.source-path path-element=${source.dir}/src/
compiler.show-actionscript-warningsfalse/compiler.show-actionscript-warning
s
doc-classes class=flashx.textLayout.CoreClasses/
doc-classes class=flashx.textLayout.EditClasses/
doc-classes class=flashx.textLayout.ConversionClasses/
doc-namespaces uri=library://ns.adobe.com/flashx/textLayout/
namespace uri=library://ns.adobe.com/flashx/textLayout
manifest=${source.dir}/manifest.xml/
jvmarg line=${asdoc.jvm.args}/
static-link-runtime-shared-libraries/
define name=CONFIG::debug value=${dbg}/
define name=CONFIG::release value=${rel}/
/asdoc
Thanks,
-Fred
-Message d'origine-
From: Alex Harui
Sent: Tuesday, March 26, 2013 1:04 AM
To: dev@flex.apache.org
Subject: Re: [1/3] Added misisng empty locales files for all supported
locales so that copylocale works
On 3/25/13 3:04 PM, Justin Mclean jus...@classsoftware.com wrote:
Hi,
Could it be time to reconsider and make copylocale more tolerant of
missing
files?
As I said this was an easier fix than changing the Java code inside
copylcoale
if you want to provide an alternative patch go ahead.
Yes, the change you made was simpler, but now you have to spend time dealing
with the Git ramifications.
Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [1/3] Added misisng empty locales files for all supported locales so that copylocale works
Hi, What would be the problem to do the opposite, check them in and not re-generate them ? Modified the build script to do this - however unable to 100% test as build release is currently broken. Justin
Release build broken
Hi, Ah yes, I never did finish the release target. I just got main and checkintests to run. If you can fix it, great, if not, I will try to get to it later in the week. Issue I'm having is to do with compiling themes no idea what is causing the error. ant themes compile: [echo] Compiling samples/themes/arcade/arcade.swc BUILD FAILED /Users/justinmclean/Documents/ApacheFlexDevelopGit/build.xml:442: The following error occurred while executing this line: /Users/justinmclean/Documents/ApacheFlexDevelopGit/samples/themes/arcade/build.xml:63: File does not exist: compiler.jar ant main to compile the SDK works but ant release' fails on above Justin
Re: Release build broken
I'm not in a good place to stop and investigate right now. Is it possible that a falcon build polluted your setup? On 3/25/13 8:33 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Ah yes, I never did finish the release target. I just got main and checkintests to run. If you can fix it, great, if not, I will try to get to it later in the week. Issue I'm having is to do with compiling themes no idea what is causing the error. ant themes compile: [echo] Compiling samples/themes/arcade/arcade.swc BUILD FAILED /Users/justinmclean/Documents/ApacheFlexDevelopGit/build.xml:442: The following error occurred while executing this line: /Users/justinmclean/Documents/ApacheFlexDevelopGit/samples/themes/arcade/build .xml:63: File does not exist: compiler.jar ant main to compile the SDK works but ant release' fails on above Justin -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
Re: Release build broken
Hi, Is it possible that a falcon build polluted your setup? Unlikely. Unless something been done that git related with that? Not tried to build falcon since the move to git. Have we missed something in the move to git that's broken the release build? Can someone do a ant release on the git checkout to see if it's just an issue with my setup or with the git move. Thanks, Justin
Re: Release build broken
I can try in a couple of hours.. Thanks, Om On Mar 25, 2013 8:56 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, Is it possible that a falcon build polluted your setup? Unlikely. Unless something been done that git related with that? Not tried to build falcon since the move to git. Have we missed something in the move to git that's broken the release build? Can someone do a ant release on the git checkout to see if it's just an issue with my setup or with the git move. Thanks, Justin
