Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Good thoughts in this thread. My current thinking is this: FalconJX is a code name for the cross-compiler, but because there is an Apache Falcon project, we need a better product name, and consider that Falcon may someday compile SWFs for the Flex SDK. Adobe already used ASC2.0, plus our version of Falcon handles MXML. We could use MXMLC2.0, but I'm not a huge fan of that. IMO, FlexJS has become a tool chain. It takes in MXML and AS and outputs SWFs or HTML/JS/CSS. We want to draw in every JS framework community to MXML-enable their components. Peter is hoping to finish a demo soon of how much easier it is to learn and use CreateJS with MXML than with the current CreateJS tutorials in JS. Maybe that will get the ball rolling downhill. We will still build out a Basic component set for lowest-level smallest-footprint apps. And we hope to build out MX and Spark-like component sets to ease migration pain for existing Flex code bases. Yes, we have CreateJS, Jquery and GoogleMaps SWCs now, mostly as proofs-of-concept. I hope to see the respective communities take over development of these SWCs and expect them to do it outside of our repos, and have independent release schedules. So that's why I'm not sure a component set that targets Stage3D and Starling has to be part of this community. It can certainly be a customer of the FlexJS tool chain, and we want it to be a customer, but we want all JS component set communities to be customers of FlexJS whether they build for SWF-first workflows or direct-to-JS workflows. Further down the road, once FlexJS grows to support distributed development, we will be able to more clearly show the benefit of SWF-first workflows for those who need it. But that's for another thread someday. My 2 cents, -Alex On 4/19/16, 4:52 PM, "Josh Tynjala" wrote: >I agree that FalconJX without the FlexJS framework is an important use >case. That's basically why I'm here contributing to the project. I want to >champion the ActionScript language, and show how FalconJX will let you use >ActionScript anywhere that JavaScript is supported. That means (now or >eventually) working with HTML, Node.js, Electron, and extensibility APIs >the like CEP panels that Harbs mentioned. > >For this use case, I think it's all about focusing on building a solid >compiler. > >- Josh > >On Tue, Apr 19, 2016 at 4:04 PM, OmPrakash Muppirala > >wrote: > >> We have an equally important component that is FalconJX. I envision >>lot of >> demand to work on non-FlexJS, pure FalconJX work. >> >> I think the Starling port falls under the category of pure FalconJX work >> and not FlexJS. We already have a game company working on making a game >> using the FalconJX compiler. >> >> Any thoughts on how we want to handle this use case? >> >> Thanks, >> Om >> >> On Tue, Apr 19, 2016 at 3:44 PM, Harbs wrote: >> >> > I missed a fifth item in my list of things we need: >> > 5. We need tooling to pull in external swcs (externs and >>cross-copiling >> > ones) when compiling to Javascript. >> > >> > (I think we also need a naming convention for the two types of swcs. >> > "definition swcs" and "code swcs”?) >> > >> > On Apr 20, 2016, at 1:37 AM, Harbs wrote: >> > >> > > Alex and Josh bring up good points. >> > > >> > > I’m thinking that I should step back and figure out what I was >>trying >> to >> > accomplish by suggesting that we accept these APIs. >> > > >> > > In fact, I think it’s time we figure out exactly what FlexJS >>actually >> is. >> > > >> > > The motivation to accept the code into FlexJS was really to empower >> > users to have access to great APIs and capabilities. However to say >>that >> > any cool functionality should become part of the core product probably >> does >> > not make sense. Case in point: I’m currently working on FlexJS support >> for >> > CEP panels in Adobe extensions. I think it’s great functionality, but >>I >> > don’t believe it belongs in the Flex repo. >> > > >> > > To address the question of exactly what belongs in the FlexJS repo, >>I >> > think we need to address exactly what is the identity of FlexJS >>actually >> > is. Different folks would probably have different definitions, but >>here’s >> > what I think: >> > > >> > > 1. It’s the compiler which turns MXML and ActionScript into >>Javascript. >> > > 2. It’s the paradigm of composing apps using MXML. >> > > 3. It’s a set (or sets) of components which is built with this >>paradigm >> > in mind. (similar to mx and spark components in the classic Flex >> framework.) >> > > 4. It’s the infrastructure which enables tools to take advantage of >> this. >> > > >> > > I think that’s pretty much it. >> > > >> > > Based on this definition, drawing APIs are probably not “Flex >>core”. In >> > fact, some of the other packages which already exist are probably also >> not >> > Flex core (such as GoogleMaps). >> > > >> > > These are all useful things, but trying to include all useful things >> > will cause a lot of bloat and actually pr
Re: [Discuss]Accept donation of drawing APIs
On 4/19/16, 5:08 PM, "Josh Tynjala" wrote: >I think there's some disagreement about the abstraction level where the >FlexJS framework lives. I've always understood that it lived at the >component level. Buttons, lists, sliders, data grids, etc. Emulating Flash >drawing APIs seems like a lower level to me. I feel like we should use the >Flash drawing APIs with Flash, but whatever is best for other targets. > >There are downsides of forcing everything to emulate the Flash APIs. For >instance, it may hurt performance in some environments. My current vision for FlexJS is to remove any Flash-like APIs from the API surface because they are hard/expensive/impossible to implement in the JS runtime. In doing so, we try to abstract away whether there is a timeline or not, we don't use weak references or Dictionary, we don't promise deferred rendering (changing the display list in JS is immediate in most cases). Otherwise, the cost to implement and run is just too high. At least, I haven't figured out any way to implement weak references or deferred rendering without a ton of work that will eat battery life. IMO, for the basic set of FlexJS components, the goal is to make the JS version smaller and faster than the SWF version when forced to make a choice. So the basic component set leverages HTMLElement when it can. Now, the Spark/MX-like component sets, assuming we can get them to work, probably will support a flash.display.Graphics object sort of thing. It doesn't care so much about size and performance. Its main goal is to minimize the API surface changes from the current Flex SDK, but it will probably leak memory: folks will have to make API calls since we don't have weak references. IMO, emulating Flash on JS is for a different community. We have enough work just trying to get the code we have to 1.0. There are probably some great things in Lizhi's code that will be useful to us, but I think our target market is more about enterprise customers sitting on large Flex code bases than on Starling. I'll say more on the bigger picture in the Identity Crisis thread. -Alex > >- Josh > >On Tue, Apr 19, 2016 at 3:09 PM, jude wrote: > >> But Flex is based on the Flash runtime and underlying API. Without the >> drawing commands, the interactive layer, point classes, event >>management, >> byte array, birthday data, mouse events, etc Flex and other frameworks >> wouldn't be possible. >> >> The Flash layer and related classes are what Flex is built on. >> >> The point of Flex JS is to run on both Flash and the browser so it's not >> entirely new. Flash is the foundation for one of those targets. we know >> what to expect from it. With Flex js the goal is to build the exact same >> house visually and functionally on two aspirate foundations. one is >>tried >> and true and the new one we're still building from the ground up. But >>for >> this to work those two foundations need to be identical IMHO. >> >> I wouldn't be opposed to having Apache Flex projects using external >> libraries from Github. But in some capacity we would need the same >>quality >> control, testing and licensing. I don't know if you can do that with an >> external library. >> >> I wouldn't worry about expectations and that shouldn't be an excuse. We >> deal with them all the time anyway. >> >> Apache was kind enough to give us a canned response, "If you have an >>itch >> scratch it yourself. If it's broke fix it yourself." since we aren't a >> corporate identity we can easily add a disclaimer, "this project is run >>by >> volunteers. The full Flash api is not supported. The project is open >> source. feel free to jump in and add missing pieces" >> >> on another note, this project could benefit from corporate sponsors and >> endorsements. feature and bug fixing bounties could help bring in the >> freelancer crowd. filling in the missing api would be quickly solved. >>... >> if anyone knows how to do this or know someone that does then we need to >> get them on board. ...side tracked again, but I bring this up bc I know >> developers who would help this project along given endorsements, >> sponsorship, branding, etc. in the same way angular is popular even >>though >> it has so many issues. The main reason it is is because Google endorses >>it. >> On Apr 19, 2016 10:40 AM, "Josh Tynjala" wrote: >> >> > I've always thought that someone implementing the Flash classes is a >>good >> > idea, but that it makes the most sense as an external project. In >>other >> > words, not included with Apache FlexJS. There's nothing wrong with >> external >> > projects. In fact, they're a sign of a healthy community! We should be >> > encouraging them and promoting them. >> > >> > I agree with Alex's points that including the Flash classes in FlexJS >> will >> > set expectations of compatibility that may not be desirable from our >> side. >> > It also keeps FlexJS bound to the legacy of Flash, instead of showing >> that >> > the project is evolving into som
Re: [FlexJS] DataItemRenderer and HorizontalLayout - question
On 4/19/16, 12:30 PM, "piotrz" wrote: >Hi, > >I was experimenting with DataItemRenderer in TodoListSampleApp. I see that >TodoItemRenderer have adjustSize method with logic which positioning >controls. - They have displayed horizontally. - Nicly in flash and js. > >I've tried create new item renderer [1] with HorizontalLayout bead. - The >result looks like that [2]. > >My question is - Do I always have to adjust position "manually"? Is it the >way how it should be done in item renderers ? Well, I didn't look into why it didn't work, but a DataItemRenderer is not a container so that could be why dropping in a HorizontalLayout didn't work. IMO, renderers shouldn't have to be heavy as containers for performance reasons. Because FlexJS is trying not to have a one-thing-for-all-scenarios philosophy, it is certainly possible to either fix HorizontalLayout, create a different HorizontalLayout that doesn't require Container, or even create things like TwoChildHorizontalLayout. You should already see layouts like OneFlexibleChildHorizontalLayout in the doc. HTH, -Alex
Re: [Discuss]Accept donation of drawing APIs
flash api,it is just a api,design good.it will not hurt performance. the api always not hurt performance -- View this message in context: http://apache-flex-development.247.n4.nabble.com/Discuss-Accept-donation-of-drawing-APIs-tp52429p52503.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [Discuss]Accept donation of drawing APIs
I think there's some disagreement about the abstraction level where the FlexJS framework lives. I've always understood that it lived at the component level. Buttons, lists, sliders, data grids, etc. Emulating Flash drawing APIs seems like a lower level to me. I feel like we should use the Flash drawing APIs with Flash, but whatever is best for other targets. There are downsides of forcing everything to emulate the Flash APIs. For instance, it may hurt performance in some environments. - Josh On Tue, Apr 19, 2016 at 3:09 PM, jude wrote: > But Flex is based on the Flash runtime and underlying API. Without the > drawing commands, the interactive layer, point classes, event management, > byte array, birthday data, mouse events, etc Flex and other frameworks > wouldn't be possible. > > The Flash layer and related classes are what Flex is built on. > > The point of Flex JS is to run on both Flash and the browser so it's not > entirely new. Flash is the foundation for one of those targets. we know > what to expect from it. With Flex js the goal is to build the exact same > house visually and functionally on two aspirate foundations. one is tried > and true and the new one we're still building from the ground up. But for > this to work those two foundations need to be identical IMHO. > > I wouldn't be opposed to having Apache Flex projects using external > libraries from Github. But in some capacity we would need the same quality > control, testing and licensing. I don't know if you can do that with an > external library. > > I wouldn't worry about expectations and that shouldn't be an excuse. We > deal with them all the time anyway. > > Apache was kind enough to give us a canned response, "If you have an itch > scratch it yourself. If it's broke fix it yourself." since we aren't a > corporate identity we can easily add a disclaimer, "this project is run by > volunteers. The full Flash api is not supported. The project is open > source. feel free to jump in and add missing pieces" > > on another note, this project could benefit from corporate sponsors and > endorsements. feature and bug fixing bounties could help bring in the > freelancer crowd. filling in the missing api would be quickly solved. ... > if anyone knows how to do this or know someone that does then we need to > get them on board. ...side tracked again, but I bring this up bc I know > developers who would help this project along given endorsements, > sponsorship, branding, etc. in the same way angular is popular even though > it has so many issues. The main reason it is is because Google endorses it. > On Apr 19, 2016 10:40 AM, "Josh Tynjala" wrote: > > > I've always thought that someone implementing the Flash classes is a good > > idea, but that it makes the most sense as an external project. In other > > words, not included with Apache FlexJS. There's nothing wrong with > external > > projects. In fact, they're a sign of a healthy community! We should be > > encouraging them and promoting them. > > > > I agree with Alex's points that including the Flash classes in FlexJS > will > > set expectations of compatibility that may not be desirable from our > side. > > It also keeps FlexJS bound to the legacy of Flash, instead of showing > that > > the project is evolving into something new and interesting. > > > > - Josh > > > > On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui wrote: > > > > > > > > > > > On 4/19/16, 12:01 AM, "Harbs" wrote: > > > > > > >webgl is not a very good name, because a lot of the code is actually > > > >canvas rather than webgl. > > > > > > OK. I realized that Lizhi has been calling it SpriteFlexJS. So that > > > could be in the package name. > > > > > > Actually this might be a good time to discuss names in terms of > business > > > models. Lizhi, I want to make sure you are aware that whatever name we > > > put on your code base will belong to Apache and you won't be able to > sell > > > software using that name. This is a public mailing list, so feel free > to > > > not answer or write me directly, but an important point is this: I'm > not > > > sure how you plan to keep contributing to the SpriteFlexJS code, but if > > it > > > involves selling the software what most people do is come up with two > > > names, one for the for-profit software and one for the open source code > > > base. For example, the Apache Subversion project doesn't let other > > > for-profit products be called Subversion, but they can use SVN. Adobe > > > PhoneGap is a for-profit product based on Apache Cordova. > > > > > > > > > > >What might make more sense would be to keep all the flash packages as > > > >experimental, and if we can identify robust piece of the package, we > can > > > >repurpose some of the code to be in separate packages. > > > > > > Another option is that we don't bring in all of this code right away. > > > Didn't this thread start based on interest in Lizhi's ByteArray? Lizhi > > > could donate that one file and we could us
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
I agree that FalconJX without the FlexJS framework is an important use case. That's basically why I'm here contributing to the project. I want to champion the ActionScript language, and show how FalconJX will let you use ActionScript anywhere that JavaScript is supported. That means (now or eventually) working with HTML, Node.js, Electron, and extensibility APIs the like CEP panels that Harbs mentioned. For this use case, I think it's all about focusing on building a solid compiler. - Josh On Tue, Apr 19, 2016 at 4:04 PM, OmPrakash Muppirala wrote: > We have an equally important component that is FalconJX. I envision lot of > demand to work on non-FlexJS, pure FalconJX work. > > I think the Starling port falls under the category of pure FalconJX work > and not FlexJS. We already have a game company working on making a game > using the FalconJX compiler. > > Any thoughts on how we want to handle this use case? > > Thanks, > Om > > On Tue, Apr 19, 2016 at 3:44 PM, Harbs wrote: > > > I missed a fifth item in my list of things we need: > > 5. We need tooling to pull in external swcs (externs and cross-copiling > > ones) when compiling to Javascript. > > > > (I think we also need a naming convention for the two types of swcs. > > "definition swcs" and "code swcs”?) > > > > On Apr 20, 2016, at 1:37 AM, Harbs wrote: > > > > > Alex and Josh bring up good points. > > > > > > I’m thinking that I should step back and figure out what I was trying > to > > accomplish by suggesting that we accept these APIs. > > > > > > In fact, I think it’s time we figure out exactly what FlexJS actually > is. > > > > > > The motivation to accept the code into FlexJS was really to empower > > users to have access to great APIs and capabilities. However to say that > > any cool functionality should become part of the core product probably > does > > not make sense. Case in point: I’m currently working on FlexJS support > for > > CEP panels in Adobe extensions. I think it’s great functionality, but I > > don’t believe it belongs in the Flex repo. > > > > > > To address the question of exactly what belongs in the FlexJS repo, I > > think we need to address exactly what is the identity of FlexJS actually > > is. Different folks would probably have different definitions, but here’s > > what I think: > > > > > > 1. It’s the compiler which turns MXML and ActionScript into Javascript. > > > 2. It’s the paradigm of composing apps using MXML. > > > 3. It’s a set (or sets) of components which is built with this paradigm > > in mind. (similar to mx and spark components in the classic Flex > framework.) > > > 4. It’s the infrastructure which enables tools to take advantage of > this. > > > > > > I think that’s pretty much it. > > > > > > Based on this definition, drawing APIs are probably not “Flex core”. In > > fact, some of the other packages which already exist are probably also > not > > Flex core (such as GoogleMaps). > > > > > > These are all useful things, but trying to include all useful things > > will cause a lot of bloat and actually probably stunt community growth. > > Until our focus was how to grow the Apache Flex community. I think we’ve > > come to a bit of a cross-roads here, and we need to figure out how to > help > > grow the community OUTSIDE Apache. > > > > > > What would accepting these APIs accomplish? I think primarily three > > things: > > > 1. Give the APis visibility. > > > 2. Help promote others to work on them. > > > 3. Make it easy for clients to use them. > > > > > > These are generalized problems and I think we need to solve them in a > > generalized way so the next person who comes up with some other awesome > > classes will have these problems solved as well. If someone builds some > > cool stuff around FlexJs, we should not need discussion to make them > useful > > and usable. > > > > > > Here’s some ideas I came up with while thinking about this: > > > > > > 1. We need a way to find tools and libraries that support FlexJS. > > > 2. We need to help external libraries automate builds of swcs. I think > > it would be really useful to publish some docs with a recommended > workflow > > for Github to do this. > > > 3. We need some kind of central repository of FlexJS swcs outside > > Apache. There should probably be two classes of swcs. Ones that are > > strictly externs, and others which actually compile into Javascript code. > > > 4. I think we need a system to create an automated build of Definitely > > Typed definitions into FlexJS swcs into a centralized repo. I think > Github > > has hooks you can use to trigger things when their repo changes. > > > > > > If these four points are addressed, I think it’ll do a lot to build the > > greater community without adding all kinds of peripherals into the core > > FlexJS repo. (and much more effectively as well) It’s not necessary for > > Apache Flex to address all these directly. If the community at large > > addresses some of them, that’s also fine (or maybe ev
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On Tue, Apr 19, 2016 at 3:37 PM, Harbs wrote: > 4. I think we need a system to create an automated build of Definitely > Typed definitions into FlexJS swcs into a centralized repo. I think Github > has hooks you can use to trigger things when their repo changes. > My dts2as utility can't handle the full repository yet, so if this were to happen, it would need to be a subset of known compatible libraries in the repository. - Josh
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
On Tue, Apr 19, 2016 at 3:44 PM, Harbs wrote: > I missed a fifth item in my list of things we need: > 5. We need tooling to pull in external swcs (externs and cross-copiling > ones) when compiling to Javascript. > When you say tooling, do you mean some kind of package management system for downloading SWCs? Or something else? > (I think we also need a naming convention for the two types of swcs. > "definition swcs" and "code swcs”?) > > Well, we've all been calling the SWCs that define JavaScript APIs "externs SWCs". I'm happy to stick with that name. - Josh
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
We have an equally important component that is FalconJX. I envision lot of demand to work on non-FlexJS, pure FalconJX work. I think the Starling port falls under the category of pure FalconJX work and not FlexJS. We already have a game company working on making a game using the FalconJX compiler. Any thoughts on how we want to handle this use case? Thanks, Om On Tue, Apr 19, 2016 at 3:44 PM, Harbs wrote: > I missed a fifth item in my list of things we need: > 5. We need tooling to pull in external swcs (externs and cross-copiling > ones) when compiling to Javascript. > > (I think we also need a naming convention for the two types of swcs. > "definition swcs" and "code swcs”?) > > On Apr 20, 2016, at 1:37 AM, Harbs wrote: > > > Alex and Josh bring up good points. > > > > I’m thinking that I should step back and figure out what I was trying to > accomplish by suggesting that we accept these APIs. > > > > In fact, I think it’s time we figure out exactly what FlexJS actually is. > > > > The motivation to accept the code into FlexJS was really to empower > users to have access to great APIs and capabilities. However to say that > any cool functionality should become part of the core product probably does > not make sense. Case in point: I’m currently working on FlexJS support for > CEP panels in Adobe extensions. I think it’s great functionality, but I > don’t believe it belongs in the Flex repo. > > > > To address the question of exactly what belongs in the FlexJS repo, I > think we need to address exactly what is the identity of FlexJS actually > is. Different folks would probably have different definitions, but here’s > what I think: > > > > 1. It’s the compiler which turns MXML and ActionScript into Javascript. > > 2. It’s the paradigm of composing apps using MXML. > > 3. It’s a set (or sets) of components which is built with this paradigm > in mind. (similar to mx and spark components in the classic Flex framework.) > > 4. It’s the infrastructure which enables tools to take advantage of this. > > > > I think that’s pretty much it. > > > > Based on this definition, drawing APIs are probably not “Flex core”. In > fact, some of the other packages which already exist are probably also not > Flex core (such as GoogleMaps). > > > > These are all useful things, but trying to include all useful things > will cause a lot of bloat and actually probably stunt community growth. > Until our focus was how to grow the Apache Flex community. I think we’ve > come to a bit of a cross-roads here, and we need to figure out how to help > grow the community OUTSIDE Apache. > > > > What would accepting these APIs accomplish? I think primarily three > things: > > 1. Give the APis visibility. > > 2. Help promote others to work on them. > > 3. Make it easy for clients to use them. > > > > These are generalized problems and I think we need to solve them in a > generalized way so the next person who comes up with some other awesome > classes will have these problems solved as well. If someone builds some > cool stuff around FlexJs, we should not need discussion to make them useful > and usable. > > > > Here’s some ideas I came up with while thinking about this: > > > > 1. We need a way to find tools and libraries that support FlexJS. > > 2. We need to help external libraries automate builds of swcs. I think > it would be really useful to publish some docs with a recommended workflow > for Github to do this. > > 3. We need some kind of central repository of FlexJS swcs outside > Apache. There should probably be two classes of swcs. Ones that are > strictly externs, and others which actually compile into Javascript code. > > 4. I think we need a system to create an automated build of Definitely > Typed definitions into FlexJS swcs into a centralized repo. I think Github > has hooks you can use to trigger things when their repo changes. > > > > If these four points are addressed, I think it’ll do a lot to build the > greater community without adding all kinds of peripherals into the core > FlexJS repo. (and much more effectively as well) It’s not necessary for > Apache Flex to address all these directly. If the community at large > addresses some of them, that’s also fine (or maybe even better). > > > > Harbs > > > > On Apr 19, 2016, at 6:39 PM, Josh Tynjala wrote: > > > >> I've always thought that someone implementing the Flash classes is a > good > >> idea, but that it makes the most sense as an external project. In other > >> words, not included with Apache FlexJS. There's nothing wrong with > external > >> projects. In fact, they're a sign of a healthy community! We should be > >> encouraging them and promoting them. > >> > >> I agree with Alex's points that including the Flash classes in FlexJS > will > >> set expectations of compatibility that may not be desirable from our > side. > >> It also keeps FlexJS bound to the legacy of Flash, instead of showing > that > >> the project is evolving into something new and intere
Re: FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
I missed a fifth item in my list of things we need: 5. We need tooling to pull in external swcs (externs and cross-copiling ones) when compiling to Javascript. (I think we also need a naming convention for the two types of swcs. "definition swcs" and "code swcs”?) On Apr 20, 2016, at 1:37 AM, Harbs wrote: > Alex and Josh bring up good points. > > I’m thinking that I should step back and figure out what I was trying to > accomplish by suggesting that we accept these APIs. > > In fact, I think it’s time we figure out exactly what FlexJS actually is. > > The motivation to accept the code into FlexJS was really to empower users to > have access to great APIs and capabilities. However to say that any cool > functionality should become part of the core product probably does not make > sense. Case in point: I’m currently working on FlexJS support for CEP panels > in Adobe extensions. I think it’s great functionality, but I don’t believe it > belongs in the Flex repo. > > To address the question of exactly what belongs in the FlexJS repo, I think > we need to address exactly what is the identity of FlexJS actually is. > Different folks would probably have different definitions, but here’s what I > think: > > 1. It’s the compiler which turns MXML and ActionScript into Javascript. > 2. It’s the paradigm of composing apps using MXML. > 3. It’s a set (or sets) of components which is built with this paradigm in > mind. (similar to mx and spark components in the classic Flex framework.) > 4. It’s the infrastructure which enables tools to take advantage of this. > > I think that’s pretty much it. > > Based on this definition, drawing APIs are probably not “Flex core”. In fact, > some of the other packages which already exist are probably also not Flex > core (such as GoogleMaps). > > These are all useful things, but trying to include all useful things will > cause a lot of bloat and actually probably stunt community growth. Until our > focus was how to grow the Apache Flex community. I think we’ve come to a bit > of a cross-roads here, and we need to figure out how to help grow the > community OUTSIDE Apache. > > What would accepting these APIs accomplish? I think primarily three things: > 1. Give the APis visibility. > 2. Help promote others to work on them. > 3. Make it easy for clients to use them. > > These are generalized problems and I think we need to solve them in a > generalized way so the next person who comes up with some other awesome > classes will have these problems solved as well. If someone builds some cool > stuff around FlexJs, we should not need discussion to make them useful and > usable. > > Here’s some ideas I came up with while thinking about this: > > 1. We need a way to find tools and libraries that support FlexJS. > 2. We need to help external libraries automate builds of swcs. I think it > would be really useful to publish some docs with a recommended workflow for > Github to do this. > 3. We need some kind of central repository of FlexJS swcs outside Apache. > There should probably be two classes of swcs. Ones that are strictly externs, > and others which actually compile into Javascript code. > 4. I think we need a system to create an automated build of Definitely Typed > definitions into FlexJS swcs into a centralized repo. I think Github has > hooks you can use to trigger things when their repo changes. > > If these four points are addressed, I think it’ll do a lot to build the > greater community without adding all kinds of peripherals into the core > FlexJS repo. (and much more effectively as well) It’s not necessary for > Apache Flex to address all these directly. If the community at large > addresses some of them, that’s also fine (or maybe even better). > > Harbs > > On Apr 19, 2016, at 6:39 PM, Josh Tynjala wrote: > >> I've always thought that someone implementing the Flash classes is a good >> idea, but that it makes the most sense as an external project. In other >> words, not included with Apache FlexJS. There's nothing wrong with external >> projects. In fact, they're a sign of a healthy community! We should be >> encouraging them and promoting them. >> >> I agree with Alex's points that including the Flash classes in FlexJS will >> set expectations of compatibility that may not be desirable from our side. >> It also keeps FlexJS bound to the legacy of Flash, instead of showing that >> the project is evolving into something new and interesting. >> >> - Josh >> >> On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui wrote: >> >>> >>> >>> On 4/19/16, 12:01 AM, "Harbs" wrote: >>> webgl is not a very good name, because a lot of the code is actually canvas rather than webgl. >>> >>> OK. I realized that Lizhi has been calling it SpriteFlexJS. So that >>> could be in the package name. >>> >>> Actually this might be a good time to discuss names in terms of business >>> models. Lizhi, I want to make sure you are aware th
FlexJS identity crisis. was: [Discuss]Accept donation of drawing APIs
Alex and Josh bring up good points. I’m thinking that I should step back and figure out what I was trying to accomplish by suggesting that we accept these APIs. In fact, I think it’s time we figure out exactly what FlexJS actually is. The motivation to accept the code into FlexJS was really to empower users to have access to great APIs and capabilities. However to say that any cool functionality should become part of the core product probably does not make sense. Case in point: I’m currently working on FlexJS support for CEP panels in Adobe extensions. I think it’s great functionality, but I don’t believe it belongs in the Flex repo. To address the question of exactly what belongs in the FlexJS repo, I think we need to address exactly what is the identity of FlexJS actually is. Different folks would probably have different definitions, but here’s what I think: 1. It’s the compiler which turns MXML and ActionScript into Javascript. 2. It’s the paradigm of composing apps using MXML. 3. It’s a set (or sets) of components which is built with this paradigm in mind. (similar to mx and spark components in the classic Flex framework.) 4. It’s the infrastructure which enables tools to take advantage of this. I think that’s pretty much it. Based on this definition, drawing APIs are probably not “Flex core”. In fact, some of the other packages which already exist are probably also not Flex core (such as GoogleMaps). These are all useful things, but trying to include all useful things will cause a lot of bloat and actually probably stunt community growth. Until our focus was how to grow the Apache Flex community. I think we’ve come to a bit of a cross-roads here, and we need to figure out how to help grow the community OUTSIDE Apache. What would accepting these APIs accomplish? I think primarily three things: 1. Give the APis visibility. 2. Help promote others to work on them. 3. Make it easy for clients to use them. These are generalized problems and I think we need to solve them in a generalized way so the next person who comes up with some other awesome classes will have these problems solved as well. If someone builds some cool stuff around FlexJs, we should not need discussion to make them useful and usable. Here’s some ideas I came up with while thinking about this: 1. We need a way to find tools and libraries that support FlexJS. 2. We need to help external libraries automate builds of swcs. I think it would be really useful to publish some docs with a recommended workflow for Github to do this. 3. We need some kind of central repository of FlexJS swcs outside Apache. There should probably be two classes of swcs. Ones that are strictly externs, and others which actually compile into Javascript code. 4. I think we need a system to create an automated build of Definitely Typed definitions into FlexJS swcs into a centralized repo. I think Github has hooks you can use to trigger things when their repo changes. If these four points are addressed, I think it’ll do a lot to build the greater community without adding all kinds of peripherals into the core FlexJS repo. (and much more effectively as well) It’s not necessary for Apache Flex to address all these directly. If the community at large addresses some of them, that’s also fine (or maybe even better). Harbs On Apr 19, 2016, at 6:39 PM, Josh Tynjala wrote: > I've always thought that someone implementing the Flash classes is a good > idea, but that it makes the most sense as an external project. In other > words, not included with Apache FlexJS. There's nothing wrong with external > projects. In fact, they're a sign of a healthy community! We should be > encouraging them and promoting them. > > I agree with Alex's points that including the Flash classes in FlexJS will > set expectations of compatibility that may not be desirable from our side. > It also keeps FlexJS bound to the legacy of Flash, instead of showing that > the project is evolving into something new and interesting. > > - Josh > > On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui wrote: > >> >> >> On 4/19/16, 12:01 AM, "Harbs" wrote: >> >>> webgl is not a very good name, because a lot of the code is actually >>> canvas rather than webgl. >> >> OK. I realized that Lizhi has been calling it SpriteFlexJS. So that >> could be in the package name. >> >> Actually this might be a good time to discuss names in terms of business >> models. Lizhi, I want to make sure you are aware that whatever name we >> put on your code base will belong to Apache and you won't be able to sell >> software using that name. This is a public mailing list, so feel free to >> not answer or write me directly, but an important point is this: I'm not >> sure how you plan to keep contributing to the SpriteFlexJS code, but if it >> involves selling the software what most people do is come up with two >> names, one for the for-profit software and one for the open source code >> base.
Re: [Discuss]Accept donation of drawing APIs
But Flex is based on the Flash runtime and underlying API. Without the drawing commands, the interactive layer, point classes, event management, byte array, birthday data, mouse events, etc Flex and other frameworks wouldn't be possible. The Flash layer and related classes are what Flex is built on. The point of Flex JS is to run on both Flash and the browser so it's not entirely new. Flash is the foundation for one of those targets. we know what to expect from it. With Flex js the goal is to build the exact same house visually and functionally on two aspirate foundations. one is tried and true and the new one we're still building from the ground up. But for this to work those two foundations need to be identical IMHO. I wouldn't be opposed to having Apache Flex projects using external libraries from Github. But in some capacity we would need the same quality control, testing and licensing. I don't know if you can do that with an external library. I wouldn't worry about expectations and that shouldn't be an excuse. We deal with them all the time anyway. Apache was kind enough to give us a canned response, "If you have an itch scratch it yourself. If it's broke fix it yourself." since we aren't a corporate identity we can easily add a disclaimer, "this project is run by volunteers. The full Flash api is not supported. The project is open source. feel free to jump in and add missing pieces" on another note, this project could benefit from corporate sponsors and endorsements. feature and bug fixing bounties could help bring in the freelancer crowd. filling in the missing api would be quickly solved. ... if anyone knows how to do this or know someone that does then we need to get them on board. ...side tracked again, but I bring this up bc I know developers who would help this project along given endorsements, sponsorship, branding, etc. in the same way angular is popular even though it has so many issues. The main reason it is is because Google endorses it. On Apr 19, 2016 10:40 AM, "Josh Tynjala" wrote: > I've always thought that someone implementing the Flash classes is a good > idea, but that it makes the most sense as an external project. In other > words, not included with Apache FlexJS. There's nothing wrong with external > projects. In fact, they're a sign of a healthy community! We should be > encouraging them and promoting them. > > I agree with Alex's points that including the Flash classes in FlexJS will > set expectations of compatibility that may not be desirable from our side. > It also keeps FlexJS bound to the legacy of Flash, instead of showing that > the project is evolving into something new and interesting. > > - Josh > > On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui wrote: > > > > > > > On 4/19/16, 12:01 AM, "Harbs" wrote: > > > > >webgl is not a very good name, because a lot of the code is actually > > >canvas rather than webgl. > > > > OK. I realized that Lizhi has been calling it SpriteFlexJS. So that > > could be in the package name. > > > > Actually this might be a good time to discuss names in terms of business > > models. Lizhi, I want to make sure you are aware that whatever name we > > put on your code base will belong to Apache and you won't be able to sell > > software using that name. This is a public mailing list, so feel free to > > not answer or write me directly, but an important point is this: I'm not > > sure how you plan to keep contributing to the SpriteFlexJS code, but if > it > > involves selling the software what most people do is come up with two > > names, one for the for-profit software and one for the open source code > > base. For example, the Apache Subversion project doesn't let other > > for-profit products be called Subversion, but they can use SVN. Adobe > > PhoneGap is a for-profit product based on Apache Cordova. > > > > > > > >What might make more sense would be to keep all the flash packages as > > >experimental, and if we can identify robust piece of the package, we can > > >repurpose some of the code to be in separate packages. > > > > Another option is that we don't bring in all of this code right away. > > Didn't this thread start based on interest in Lizhi's ByteArray? Lizhi > > could donate that one file and we could use it under a different package > > name. > > > > > > > >I see value in keeping the flash packages as such, because it will > likely > > >help spur more people who want complete “flash-like” APIs to do work on > > >it. As Lizhi points out, there are incomplete areas in his code. > > > > > >As far as demand for Flash and Starling goes: I expect that folks who > > >want more support will have to help out in improving it. Again, I hope > > >this will help attract more people to work on it. > > > > In short, I'm just wondering if the work on Flash and Starling is Flex. > > Should it have its own community? FlexJS will hopefully have many > > customers and not all of their code should be in our code base. > > > > -Alex >
[FlexJS] DataItemRenderer and HorizontalLayout - question
Hi, I was experimenting with DataItemRenderer in TodoListSampleApp. I see that TodoItemRenderer have adjustSize method with logic which positioning controls. - They have displayed horizontally. - Nicly in flash and js. I've tried create new item renderer [1] with HorizontalLayout bead. - The result looks like that [2]. My question is - Do I always have to adjust position "manually"? Is it the way how it should be done in item renderers ? [1] https://paste.apache.org/u8PL [2] http://images.devs-on.net/Image/8rD5081eoKZwXYB5-Region.png Piotr - Apache Flex PMC piotrzarzyck...@gmail.com -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-DataItemRenderer-and-HorizontalLayout-question-tp52494.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [Discuss]Accept donation of drawing APIs
I've always thought that someone implementing the Flash classes is a good idea, but that it makes the most sense as an external project. In other words, not included with Apache FlexJS. There's nothing wrong with external projects. In fact, they're a sign of a healthy community! We should be encouraging them and promoting them. I agree with Alex's points that including the Flash classes in FlexJS will set expectations of compatibility that may not be desirable from our side. It also keeps FlexJS bound to the legacy of Flash, instead of showing that the project is evolving into something new and interesting. - Josh On Tue, Apr 19, 2016 at 8:05 AM, Alex Harui wrote: > > > On 4/19/16, 12:01 AM, "Harbs" wrote: > > >webgl is not a very good name, because a lot of the code is actually > >canvas rather than webgl. > > OK. I realized that Lizhi has been calling it SpriteFlexJS. So that > could be in the package name. > > Actually this might be a good time to discuss names in terms of business > models. Lizhi, I want to make sure you are aware that whatever name we > put on your code base will belong to Apache and you won't be able to sell > software using that name. This is a public mailing list, so feel free to > not answer or write me directly, but an important point is this: I'm not > sure how you plan to keep contributing to the SpriteFlexJS code, but if it > involves selling the software what most people do is come up with two > names, one for the for-profit software and one for the open source code > base. For example, the Apache Subversion project doesn't let other > for-profit products be called Subversion, but they can use SVN. Adobe > PhoneGap is a for-profit product based on Apache Cordova. > > > > >What might make more sense would be to keep all the flash packages as > >experimental, and if we can identify robust piece of the package, we can > >repurpose some of the code to be in separate packages. > > Another option is that we don't bring in all of this code right away. > Didn't this thread start based on interest in Lizhi's ByteArray? Lizhi > could donate that one file and we could use it under a different package > name. > > > > >I see value in keeping the flash packages as such, because it will likely > >help spur more people who want complete “flash-like” APIs to do work on > >it. As Lizhi points out, there are incomplete areas in his code. > > > >As far as demand for Flash and Starling goes: I expect that folks who > >want more support will have to help out in improving it. Again, I hope > >this will help attract more people to work on it. > > In short, I'm just wondering if the work on Flash and Starling is Flex. > Should it have its own community? FlexJS will hopefully have many > customers and not all of their code should be in our code base. > > -Alex > >
Re: [Discuss]Accept donation of drawing APIs
On 4/19/16, 12:01 AM, "Harbs" wrote: >webgl is not a very good name, because a lot of the code is actually >canvas rather than webgl. OK. I realized that Lizhi has been calling it SpriteFlexJS. So that could be in the package name. Actually this might be a good time to discuss names in terms of business models. Lizhi, I want to make sure you are aware that whatever name we put on your code base will belong to Apache and you won't be able to sell software using that name. This is a public mailing list, so feel free to not answer or write me directly, but an important point is this: I'm not sure how you plan to keep contributing to the SpriteFlexJS code, but if it involves selling the software what most people do is come up with two names, one for the for-profit software and one for the open source code base. For example, the Apache Subversion project doesn't let other for-profit products be called Subversion, but they can use SVN. Adobe PhoneGap is a for-profit product based on Apache Cordova. > >What might make more sense would be to keep all the flash packages as >experimental, and if we can identify robust piece of the package, we can >repurpose some of the code to be in separate packages. Another option is that we don't bring in all of this code right away. Didn't this thread start based on interest in Lizhi's ByteArray? Lizhi could donate that one file and we could use it under a different package name. > >I see value in keeping the flash packages as such, because it will likely >help spur more people who want complete “flash-like” APIs to do work on >it. As Lizhi points out, there are incomplete areas in his code. > >As far as demand for Flash and Starling goes: I expect that folks who >want more support will have to help out in improving it. Again, I hope >this will help attract more people to work on it. In short, I'm just wondering if the work on Flash and Starling is Flex. Should it have its own community? FlexJS will hopefully have many customers and not all of their code should be in our code base. -Alex
Re: [Discuss]Accept donation of drawing APIs
webgl is not a very good name, because a lot of the code is actually canvas rather than webgl. I think that expectations can be set using documentation. We can label flash packages as “experimental” or something similar, so clients would be aware that it will likely be incomplete. What might make more sense would be to keep all the flash packages as experimental, and if we can identify robust piece of the package, we can repurpose some of the code to be in separate packages. I see value in keeping the flash packages as such, because it will likely help spur more people who want complete “flash-like” APIs to do work on it. As Lizhi points out, there are incomplete areas in his code. As far as demand for Flash and Starling goes: I expect that folks who want more support will have to help out in improving it. Again, I hope this will help attract more people to work on it. The legal concerns of using the flash package name seems really far-fetched to me. On Apr 19, 2016, at 8:56 AM, Alex Harui wrote: > Warning: I can't decide if I'm just playing devil's advocate or am truly > concerned about this, but below are some worst-case scenarios, which may > need to be taken with a grain of salt. > > My latest proposal is that we rename packages from "flash.* to "webgl.*" > and teach the compiler how to map things. And maybe also update the > reflection library to be aware that there was a mapping. We might end up > having the compiler do this sort of thing to migrate Flex code bases as > well. Yes, it may mean that migration isn't automatic. But IMO, until we > find a clean way to do weak references in JS, there is going to have to be > some migration pain. > > On 4/18/16, 6:47 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" > wrote: >> >> We already have package names like jquery.*.* and createjs.*.* where we >> are >> using the same package names for consistency. Are we proposing to change >> all those package names as well, so that we dont set expectations of doing >> everything that jquery does? > > The jquery and createjs implementations actually use Jquery and CreateJS > on the JS side, so it should meet expectations. > > There is a potential outcome where we end up having more demand for Flash > emulation in JS than Flex. Or spending more time on Starling than on > Flex. If that's where the community wants to go, I can't stop it, but > this project is called Flex. And, IMO, the big money is in enterprise > code bases in Flex. > >> >> If it turns out that that lot of folks complain about the classes not >> meeting the expectations, we could probably add the features or worst case >> swap the package names to flex.* > > We can change the package names and have the compiler do-the-right thing. > If we set the precedence of using "flash" it will be harder to change in > the future. We'll get backwards compatibility complaints and the search > engines will turn up "flash" stuff for a long time. When I think about > the person-hours devoted to Flash at Adobe, it is hard to imagine this > community finding the time to even do a fraction of that investment. It > seemed like even Google was having trouble making Pepper Flash a true > equivalent. > > And there might be increased legal issues due to things like this [1]. > > -Alex > > [1] http://blog.smartbear.com/apis/api-copyright-and-why-you-should-care/ > > >
