« November 2005 | Main | January 2006 »

December 22, 2005

Compiling ActionScript 3 and MXML on Mac and Linux

I finally switched back to Mac from Windows yesterday. I had moved to Windows a couple of months ago so that I could use the Flex Builder 2 alpha. However, after my 4th system failure in the past 3 months, I decided it was time to go back to Mac.

One of the first things I wanted to set up was my development environment so that I could continue to develop in Flex 2 and ActionScript 3. We do not currently have a Mac version of Flex Builder, but fortunately, the command line compiler (mxmlc) included with Flex builder is written in Java, which means it should (and does) run on Mac and Linux.

NOTE, currently, mxmlc is supported on windows only. The instructions below work well, but running mxmlc on non-Windows system is currently not supported.

The MXMLC compiler that is included with Flex Builder comes with a Windows executable wrapper (mxmlc.exe) that makes it very easy to use on Windows. However, you can not use the wrapper on Mac or Linux. Getting the compiler to run is not too difficult once you figure it out, although it can require constructing a pretty extensive command to run. In order to make this easier, I wrote my own simple bash script that acts as a wrapper for mxmlc and makes it easy to compile ActionScript 2 and Flex 2 applications from the command line on Mac and Linux.

First, you need to download the compiler and set it up on your system. We have a page on the Labs wiki that describes how to do this on non-Windows systems.

Once the compiler is setup, calling MXMLC is not too difficult. Here is a typical command line to compile a simple application:

java -jar "/Users/mesh/bin/flex/lib/mxmlc.jar" -flexlib "/Users/mesh/bin/flex/frameworks/" MyApp.as

That would work as long as the application only used Flash Player APIs, and not external ActionScript libraries. If it used external ActionScript classes, then you would need to specify the ActionScript classpaths like so:

java -jar "/Users/mesh/bin/flex/lib/mxmlc.jar" -flexlib "/Users/mesh/bin/flex/frameworks/" -actionscript-classpath /Users/mesh/src/flashplatform/projects/corelib/trunk/src/actionscript3/ /Users/mesh/src/flashplatform/projects/testlib/trunk/src/actionscript3/ MyApp.as

This specifies two paths to search for classes. As you can see, it begins to get a little more tedious to construct the command line. However, the Flex engineers considered this, and created a config file that the mxmlc compiler uses. You can find this setting in the frameworks/flex-config.xml file.

If we add the following to the file (just un-comment the entry already in the file):

<actionscript-classpath>


 <path-element</Users/mesh/src/flashplatform/projects/corelib/trunk/src/actionscript3/</path-element>



 <path-element</Users/mesh/src/flashplatform/projects/testlib/trunk/src/actionscript3/</path-element>       



</actionscript-classpath>


then MXMLC will know where to look for ActionScript classes, and we will no longer need to specify them on the command line.

But, that still brings us back to:

java -jar "/Users/mesh/bin/flex/lib/mxmlc.jar" -flexlib "/Users/mesh/bin/flex/frameworks/" MyApp.as

which is still a little tedious to type each time you want to compile the application.

So, I wrote a simple bash script that wraps mxmlc.

First, create a new text file on your machine (I called it mxmlc), and add the following script to it:

#!/bin/bash


flex='/Users/mesh/bin/flex/'



classpath=''



if [ -n "$ASCLASSPATH" ]; then

        classpath="-actionscript-classpath `echo $ASCLASSPATH | sed 's/:/ /g'`"

fi



echo $classpath



java -jar "$flex/lib/mxmlc.jar" -flexlib "$flex/frameworks/" $classpath --incremental=true $@

Make sure to change the:

flex='/Users/mesh/bin/flex/'

to point to the folder that contains your flex files (that you installed according to the instructions here). Not that the script adds the --incrental=true flag. This enables incremental compilation and should dramatically increases compilation performance.

Next, from the command line you need to make sure that the script is executable, so run this command on it:

chmod 755 mxmlc

Once you have done that, you can now compile your applications like so:

mxmlc MyApp.as

The script is written so that you can also pass any supported mxmlc command line arguments to it, like so:

mxmlc -verbose MyApp.as

It also supports a system level ActionScript classpath. If you want to specify your ActionScript classpath in the system, and not in the flex-config.xml file (similar to a Java classpath), just specify an $ASCLASSPATH environment variable, that contains a colon ":" separated lists of ActionScript classpath.

For example, my .profile file in my home directory contains this line:

ASCLASSPATH=/Users/mesh/src/flashplatform/projects/corelib/trunk/src/actionscript3/:/Users/mesh/src/flashplatform/projects/testlib/trunk/src/actionscript3/


export ASCLASSPATH

Now, any application or script on my system can access my ActionScript classpath. If this is set, then the mxmlc script will use it when compiling the application. Of course, you can continue to specify it on the command line or via the flex-config.xml file.

Here are some additional resources on using mxmlc:

Hope that help makes compiling on Mac and Linux easier. If you have any comments / suggestions / corrections, please post them in the comments.

Posted by mesh at 9:05 AM | Comments (21)

December 9, 2005

Flash Player and Acrobat Reader merging?

There has been quite a lot of confusion this week over one of the items in the Adobe / Macromedia acquisition FAQ. Specifically, the following question:

What are Adobe's plans for Flash Player and Adobe Reader?

was not worded well initially. Quite a few people in the community interpreted the answer as saying that the Flash Player and Acrobat Reader were going to combine into one uber web browser plugin.

That is not correct.

We have updated the FAQ answer to try and clarify this:

Our long-term plan is to develop a "universal client" by combining PDF, Flash and HTML in a single, integrated runtime. Of course, we will continue delivering the Flash Player as a small, efficient runtime for content and applications on the web, and Adobe Reader for viewing and interacting with PDF documents and forms. The integration of these technologies into a unified framework creates a ubiquitous platform that runs on virtually every device, and dramatically expands the opportunities to create compelling solutions.

However, there still seems to be some confusion.

So, in order to help clarify this further:

WE HAVE NO PLANS TO COMBINE THE FLASH PLAYER AND ACROBAT READER WEB BROWSER PLUGINS.

One of the primary reasons for the success of the Flash Player is that we have been able to keep the download size small. While the size will grow in the future, we are not going to do ANYTHING that jeopardizes the ubiquity of the player.

The "universal client" mentioned above is referring to the Apollo project, which is a project in its early stages focused at creating a client that allows developers to create and deploy apps and content using a combination of Flash, HTML and PDF. You can think of it as a successor to Central.

The only public discussion we have had about Apollo has been in some recent keynotes, where Kevin Lynch laid out some of our early ideas / thoughts about Apollo.

You can find a summary of Kevin's Apollo discussion at MAX here.

You can view a video of Kevin's discussion of Apollo during the MAX keynote here (Day 1 > Platform Future).

Posted by mesh at 9:49 AM | Comments (10)

December 5, 2005

Macromedia News Firefox Extension for 1.5 Beta / Update

I have uploaded a beta version of the soon to be renamed Macromedia News Firefox extension that (kind of) works with Firefox 1.5. There are some significant known issues with this build, so I am not adding it to the main extension page. You can only download it from here. Download Macromedia News Firefox Extension Beta I had hoped to fix all of the issues before posting it, but decided to post it for two reasons:
  1. Tons of people have been asking me to update it
  2. I am having trouble fixing one of the issues, and maybe by releasing it, someone might have an idea of what is going on
Here is the main issue. Something in Firefox 1.5 changed, so that when I call MenuPopup.childNodes, some of the nodes are now null, where as they used to contain the nodes of the menu. Because of this, the menu cannot clear itself (since I can't remove the nodes that come through as null), before it is rebuilt. The odd thing is that the the childNodes length is correct, but that some of the node references within it are just null. You can reproduce this with the following steps:
  1. Install the extension, and restart Firefox
  2. Open the preferences, and change the "View Items" setting to "Chronologically"
  3. Save the settings
  4. View the menu
Notice that the menu is all messed up. Basically, the clearMenu function was not able to remove some of the menu items because it could not get a reference to them. If you restart Firefox, then everything will draw correctly with the new preferences. If you are interested in looking at the code, simply rename the extension file to .zip and unzip it. The code is in: 
chrome\macromedianews\content\macromedianews\macromediaNewsOverlay.js
You can also look at and modify the installed extension within the Firefox install by looking at 
\Mozilla\Firefox\Profiles\ACTIVEPROFILE\extensions\{1d6fc8a9-d399-4629-ade8-c4013c2e5c0f}
which on Windows is found in the Application Settings directory. Changes to this code will be run once you restart Firefox. Finally, you can find info on developing and debugging Firefox extensions here. The bug manifests itself in the clearMenu call, although that is not where it originates. Here is a modified clearMenu function that dumps / alerts the nodes and shows that some are null: [code]function clearMenu() { var cNodes = newsMenuPopup.childNodes; var cLen = cNodes.length; var node; var val; for(var i = 0; i < cLen; i++) { node = cNodes[i]; dump("Node : " + i + " : " + node); alert("Node : " + i + " : " + node); if(node.getAttribute("isNewsItem") == "true") { val = node.getAttribute("value"); if(val.length > 0) { oldMenuHash[val] = (node.getAttribute("isNew") == "true"); } newsMenuPopup.removeChild(node); } else if(node.getAttribute("isNewsItemHeader") == "true") { newsMenuPopup.removeChild(node); } else if(node.getAttribute("isNewsItemSeperator") == "true") { newsMenuPopup.removeChild(node); } } }[/code] I am going to keep working on it and try to figure out what is going on (or what changed in Firefox 1.5 that broke this). If anyone has any ideas / thoughts about what is going on, or questions about the code, then post them in the comments.

Posted by mesh at 2:55 PM | Comments (11)