Yep, that's the plan. I'm still trying to catch up on what web developers are doing these days and I haven't heard IDE's come up much (anyone wishing to share I would appreciate it). It seems like people are using code editors like Brackets and vim. There are some tools that run preprocessing or post processing on CSS, others that minify JS, others that do other stuff. Some people have terminal open watching a directory to run these things. I wish I could tell you more. So, to me it would be nice to create the Flex JS project directory, then have a button to compile or watch the project. Maybe a launch button or something.
By contrast, if we were writing HTML you would edit the page, cmd + s and then refresh in the browser. With FlexJS we have edit, save, compile, refresh. There's that one extra step. With a lightweight FlexJS app we could compile on a different thread in the background and return errors and warnings. They could still use the same workflow. It wouldn't be much but something someone can use to get started. People would use their own editors. I'm not sure if I mentioned it but there is a wrapper class <https://github.com/monkeypunch3/flexcapacitor/blob/master/MainLibrary/src/com/flexcapacitor/controls/AceEditor.as> for the Ace editor <http://ace.c9.io/>. You can embed that in your AIR apps. There is also a web version. We could use that for view source. Check it out. There's a lot you can do with it. It's possible to support AS3 and MXML code completion but someone has to write the language files for it or at least hook into the code completion extension points dynamically. I looked into it briefly and it was over my head. FYI I haven't supported the full Ace API but it's getting there. It was half, now it's about 3/4. It's not hard to add more just other priorities. There's an example project that shows how to use it. I might be able to post it here if we can post zips. For now, I would be focusing on just making a few buttons create, compile and launch projects (maybe also install). I'm glad to hear the Apache Installer takes care of installing FlexJS. Can someone post a link to the ant build file (that compiles a project) I should be studying and nightly source for the Apache installer (that has the ant build that installs FJS)? On Thu, Nov 5, 2015 at 5:10 PM, Alex Harui <aha...@adobe.com> wrote: > Jude, > > Are you envisioning some sort of a mini-IDE? One button creates a new > project, another button compiles it, another button cross-compiles it? > That would be cool. Especially for folks who don’t have FB or IntelliJ. > Not sure what to do about code editing and debugging though. > > Another related idea that has been in the back of my mind is that we don’t > have a way to do “Source View” without an IDE. Of course, you can see the > output JS in any browser debugger, but I wonder if packaging and viewing > the MXML and AS for the app would help with adoption. IMO, the compiler > should be mostly capable of doing it by adding a new emitter so that’s a > project for anyone wanting to code in Java, but on the other hand, if a we > didn’t package up annotated HTML of the MXML and AS and had some sort of > AIR app that would colorize the source automatically, that would be cool > too, but you would need some sort of AST to do it, I think. > > -Alex > > On 11/5/15, 4:52 PM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > >As Alex said, most people who want to try out FlexJS 0.5.0 will simply use > >the Apache Flex SDK Installer. It'll be super easy for them. In fact, you > >can already install the nightlies and RC1 using the installer if you > >right-click and choose Show Dev Builds. Once 0.5.0 is released, the build > >will show up on the regular list, obviously. > > > >People who are having trouble with building are trying to build from the > >source distribution and/or the Git repository. Things are a little more > >complicated that way, but the vast majority of people won't need to deal > >with that type of build. > > > >- Josh > > > >On Thu, Nov 5, 2015 at 3:21 PM, jude <flexcapaci...@gmail.com> wrote: > > > >> Alex, > >> I'm going to go ahead and put together an app so that you can install > >> FlexJS with one click and compile. I want it to be as simple as possible > >> for anyone (new web developers). I've downloaded the build script and > >> looked over it but there is some code in it for voting and release. I'm > >> sure you will be repeating yourself again but here's my requirements: > >> > >> • button to validate FlexJS requirements (paths, etc) > >> • button to set paths for the user > >> • one button to download FlexJS > >> • another button to run FlexJS on a project app (without an IDE) > >> > >> Are there targets to do each of these (or where should I start)? Since > >>it's > >> an AIR app I want to run each target independently. BTW I'm bundling ant > >> with the app so that the user doesn't have to install anything extra. If > >> someone has FB or IntelliJ installed does the install directory need to > >> change? I'll put the project on github or post it to the group as soon > >>as > >> it's usable. > >> > >> > >> On Thu, Nov 5, 2015 at 6:32 AM, Alex Harui <aha...@adobe.com> wrote: > >> > >> > > >> > > >> > On 11/5/15, 3:56 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> > > >> > >I’m a bit confused about the release process. > >> > > > >> > >I thought we were creating release branches in git for each release > >>to > >> > >“freeze” the code, so we do not have a wildly moving target. It does > >>not > >> > >seem like that’s happening, so I’m not sure if I just misunderstood. > >> > > >> > You understand correctly. I’m cheating right now because it is just > >>more > >> > work to set up release branches, and there isn’t a lot of non-critical > >> > work going on the develop branch. Peter and I are working on the back > >> > port from JS to AS in a separate branch. Only important fixes are > >>being > >> > pushed to develop. If we had more folks contributing more often, > >>then I > >> > would have used a release branch. > >> > > >> > Even release branches have historically moved because folks don’t > >>start > >> > testing until late in the game and find important bugs. > >> > > >> > -Alex > >> > > >> > > > >> > >Harbs > >> > > > >> > >On Nov 3, 2015, at 12:04 AM, Alex Harui <aha...@adobe.com> wrote: > >> > > > >> > >> > >> > >> > >> > >> On 10/30/15, 3:19 PM, "Justin Mclean" <jus...@classsoftware.com> > >> wrote: > >> > >> > >> > >>> Hi, > >> > >>> > >> > >>>> Hmm, I was hoping more PMC folks would respond. Remember that, > >> > >>>> according > >> > >>>> to the release process, the PMC folks planning to vote are > >>supposed > >> to > >> > >>>> be > >> > >>>> running tests now. In theory, the only new test to be run after > >>we > >> > >>>> start > >> > >>>> the vote is whether the PGP signature is valid. > >> > >>> > >> > >>> We’re continually trying to test a moving target which involves a > >> > >>>greater > >> > >>> time commitment that I currently have available. You’ve never > >>quite > >> > >>>sure > >> > >>> if the version you testing is going to be the version in the > >>release > >> > >>> candidate and unless you very carefully follow all of the commits > >> it’s > >> > >>> not obvious what needs to be retested at two different time > >> intervals. > >> > >> > >> > >> Hmm, pleading is working so maybe I’ll try guilt-tripping. > >> > >> > >> > >> Yes, the nightly builds are a moving target. IMO, we all want to > >>grow > >> > >>the > >> > >> community by attracting customers and hopefully convert a few to be > >> > >> committers and the only way I know to do it is to keep making the > >>code > >> > >> better and releasing the best release we can in the most efficient > >> > >>manner. > >> > >> IMO, freezing a branch and not allowing important bug fixes that > >>might > >> > >> make a difference in whether someone becomes more active in our > >> > >>community > >> > >> doesn’t make sense. Taking the time to build out an RC and post it > >> and > >> > >> start a vote thread in order to finally get some testing isn’t very > >> > >> efficient either. > >> > >> > >> > >> Historically, when we produced an RC and immediately started a > >>release > >> > >> vote, bugs would be found and we’d cancel the RC and roll out > >>another > >> > >>one. > >> > >> The goal of the release process we voted in, IMO, was to reduce > >>this > >> > >> overhead of posting RCs, opening and closing vote threads, etc. so > >>we > >> > >>can > >> > >> more efficiently achieve the goal of serving our customers and > >> > >>attracting > >> > >> some of them to becoming committers so we can have more people find > >> bugs > >> > >> sooner by working with the develop branch. > >> > >> > >> > >> Recently, I’ve spent several days on improving build and approval > >> > >>scripts > >> > >> so testing what is in development takes less time. In theory, you > >>can > >> > >>now > >> > >> start up the approval script which will pull down the bits, answer > >>a > >> few > >> > >> questions, then go do something else for 5 to 25 minutes and then > >>come > >> > >> back and poke at it. I would have rather spent that time on > >>features > >> > >>for > >> > >> our customers, but I gambled that this would help us get the > >>release > >> out > >> > >> sooner. I’m not sure that paid off. > >> > >> > >> > >> > >> > >> I don’t have any other ideas on how to make it easier for those of > >>you > >> > >>who > >> > >> contribute in your spare time to stay up on the commits and bugs. > >>It > >> > >> should be ok to take any nightly build and run it through your > >>tests > >> and > >> > >> report your findings. Ideally, you would be up to date on the > >>commits > >> > >>and > >> > >> bugs and other discussions to know whether what you find is a > >> duplicate > >> > >>or > >> > >> not, but at this point, I don’t care if you report a duplicate. At > >> > >>least > >> > >> that means you verified a bunch of other code paths worked for > >>you. I > >> > >> don’t know how other Apache projects with really active code bases > >>do > >> > >>it. > >> > >> > >> > >> It is certainly fine to be too busy to vote on a release. I was > >> hoping > >> > >>to > >> > >> get more folks to poke at the bits before starting a vote because > >>it > >> > >>will > >> > >> be a waste of community energy to start a vote and then have a > >>bunch > >> of > >> > >> PMC voters jump in and start reporting important bugs. But I think > >> the > >> > >> community has waited too long already, so I am going to start a > >>vote > >> > >>soon, > >> > >> and Peter and I will vote and maybe Josh and/or Harbs and we’ll be > >> good > >> > >>to > >> > >> go. Hopefully any others jumping in late won’t find release > >>blockers > >> > >>and > >> > >> we’ll just make another release later. > >> > >> > >> > >> > >> > >> -Alex > >> > > > >> > > >> > > >> > >
