Yesterday, Adobe published their long-awaited “roadmap” for Flex: Adobe’s view of Flex and its commitments to Flex in the future. Sadly for those of us involved in the Apache Flex podling, the following piece is seriously bad news: Continue reading “Project Goshawk — Apache Flex’s own compiler?”
Install them and try your favourite content out with the betas.
If you find a bug, be sure to let Adobe know.
Finally, why not help spread the word by passing on details of this beta test drive via your own blog or twitter?
I want to add some more here in response to the comments so far. I thought long and hard over whether to get involved in this beta bug request as only this morning I was looking at a bug – ClassReference in nested CSS file compiled to SWF causes error – that was closed as “deferred” two years ago. Stefan Richter had highlighted it as an example of how Adobe mess up with bugs at times. The problem remains unfixed and Adobe’s communications were crap with this bug as they didn’t explain why they chose to ignore it. However, in the end I decided it would be wrong to focus on such negatives at the expense of the great stride Adobe have made toward openness.
They have a open bug reporting system. A lot of the flash development environment is open (the whole of Flex Framework for example.) Part of opening up to the community involves inviting the community to give back to the project, both in terms of bug reports and bug fixes. Adobe have frequently highlighted the fact that people are welcome and encouraged to not only report bugs, but to help fix them too. So to those that complain bugs remain languishing unfixed for long periods of time, I have a simple question for you: have you tried contributing to the openness of Flash by helping fix that bug?
Toward the end of the keynote, we were at least treated to some sneak peaks at upcoming features in the next release of the Flash Pro authoring tool, including better integration with FlashBuilder. There was also a hint that there might be news on Flash Player 10 finally appearing on smart phones (though presumably not the iPhone) at MAX.
Next up was a presentation on AIR by Mike Chambers. It was a curious mix of self-promotion of his as3corelib project and some details on features coming in AIR 2.0. The latter is to gain built-in support for detecting removable drives being mounted/ unmounted and a new native application mode. The native mode will be built as a .exe (or the MAC equivalent) and can communicate with other native applications via stdin and stdout pipes. This seems an odd solution when the likes of Mike’s own Command Proxy project offer a much richer solution already. I guess we will have to wait for more details from MAX to understand the solution better.
The only other session of note – in this developer’s view – was a session on Spark by Mike Jones. Sadly Adobe have dumped the great name “gumbo” and replaced it with the far more boring “spark” for their new skinnable component set. The session described the current state of the spark components (subject to change of course as it’s all still in beta). Despite many criticising the namespace in CSS solution Adobe came up with to support both halo and spark in the one application, I personally think it’s a very nice solution. Catalyst remains a odd one. At the moment it just doesn’t work to my mind: it is too product-skin focused and only really goes one way from designer -> developer. I fully agree with Mike’s hope that the final product better support general (and custom) component skinning and that it better support a two way design/ develop workflow.
Tomorrow has far more developer-orientated content than today, so hopefully should prove a more fruitful day for me.
Flash Builder 4
This is the new name for Flex Builder 4, as Adobe feel the Flex moniker was putting AIR and pure As3 developers off using it. The beta download is for the “Premium” version. According to the Flash Builder 4 FAQ on the Adobe Labs site, this is a name change from the fully-featured Flex Builder’s “Professional” tag to avoid confusion between Flash Builder and the Flash designer program, Flash CS4 Professional. Giving the Flash designer package a proper name would have caused a lot less confusion, but at least they have given it a bit of thought.
Flash Builder 4 can be installed as a stand-alone application alongside an installation of Flex Builder 3. So it is possible to test out the beta without losing one’s production environment. Everyone can enjoy a 30 day trial, but you’ll need a Flex Builder 3 license key if you wish to use it longer.
Flash Catalyst 4
A new addition to the Adobe stable, this tool is designed to fill the gap between Flash developers and designers in a way that the Flash designer program couldn’t. It allows the designer to turn their static picture designs into MXML code, which in turn can be used to skin the new Flex 4 components (sadly the term “gumbonents” has inevitably been dropped as the new components of now Spark components, rather than Gumbo ones.)
Having installed the beta and experimented with it for twenty minutes or so, my immediate reaction is one of “eh?” It doesn’t seem very intuitive to this developer. The tutorial info on the Adobe Labs is going to be essential reading.
Gumbo is the code name for the forthcoming Flex 4. It is due for release in the second half of this year (2009), though two beta releases are planned for the next six months. Gumbo offers a huge range of new – and useful – features, such as ASDoc support within MXML files, simple two-way data binding and support for Pixel Bender (see below). The two key features though are:
- Components become easily skinnable. The whole way that components are created has been recoded, and there is now a clear divide between a component’s functionality and appearance. These new skinnable components have been given the nickname “gumbonents”.
- The MXML 2009 specification has been expanded to include FXG (see below). This means that you can add simple shapes (or complex shapes built up from simple primitives) to your MXML, data bind them and easily skin them using the “gumbonent” skinning method.
You can read lots more about Gumbo on the Adobe Labs Gumbo site.
In Adobe’s own words:
“[FXG is ] an XML-based graphics interchange format for the Flash Platform. FXG contains high-level graphical and text primitives that can be used to create, group, transform and visually modify basic vector and bitmap shapes.”
Flex 4 sees the old MXML 2006 specification replaced with a shiny new MXML 2009 specification, which includes support for vector shapes and bitmap graphics, and also allows for things such as data binding to bitmap shapes and the like. FXG is a cut down version of this extension, allowing graphics to be described in an MXML-like form, with all the code-related stuff stripped out. What makes FXG exciting is that the users of CS4 products such as Photoshop can save their graphical creations as FXG files, allowing for the easy use of designs created with professional design tools within Flex.
See the FXG specification for more details.
This was the code name for a forthcoming product now called “Flash Catalyst” (see below).
This is a not-yet-released designer and developer tool for taking designs created in Photoshop etc and turning them into MXML code. It allows elements of the design to be identified as Flex components. The tool then generates the skin MXML required to allow the Flex application to behave as the designer wants. This tool fills the obvious gaping void that currently exists between design and implementation that currently exists within the Flex world.
See the Flash Catalyst section of Adobe labs for more details.
This was the code name for Adobe AIR 1.5, which was released last November. It added support for the new Flash 10 features, such as enhanced sound, 3D support, decent (finally!) text support etc, along with support for encrypted – rather than plain-text – data stores. It is fully compatible with Flex 3. FlexBuilder 3.02 provides support for it.
Pixel Bender is a new technology being built into multiple Adobe products, rather than being a product in its own right. At the time of writing, Flash 10 supports it natively and there is a Photoshop plugin available for applying Pixel Bender filters to Photoshop images. Flex 4 will also support it. It provides a hardware and platform-independent language for describing filters that can be applied to a set of data. Whilst the primary purpose is for manipulating graphical data (or images if you prefer) via filters, it is also likely to have uses in manipulating sound data for example. It is designed around very fast manipulation of “pixels” in isolation, or near-isolation (eg, taking into account its near neighbours). As such it will not be of use in generating histograms of an image, in generating hashes etc.
See the Adobe labs page on Pixel Bender for more details.
Whilst this isn’t an Adobe product, it relates closely to the new FXG features of Flex 4. It is a 3rd party extension to Flex 2 & 3 that provides support for low-level graphics primitives just as FXG/ MXML 2009 does. Whilst Adobe are making noises over working with the Degrafa team to ensure there is good interoperability between FXG and Degrafa, it is difficult to see a future for this product. The developers remain upbeat that Degrafa offers more and will have a future. Just as PaperVision didn’t die when Flash 10 (with built-in 3D support) was released, so Degrafa may not be killed off by FXG and may build on it instead.
If you are looking for FXG-like features from Flex 2 or 3 and cannot wait six months (or do not wish to upgrade to Flex 4), then Defraga has something to offer. Otherwise it’s probably best to wait for Flex 4.