Flex on Ubuntu: The Complete How To Guide

ubuntu_flex

I usually live with the axiom that whatever you can find in the realm of Windows and proprietary software, you can easily find in the realm of Linux (any flavor) and open source. While this is indeed usually the case, when it comes to a Flex IDE for Ubuntu, there’s a real gap. Adobe has their Flash IDE for willing and paying Windows users, and I am happy to say that I was one of these happy customers a while ago. But since then, Ubuntu has taken over my life, and when I set out to make a small Flex app a couple of days ago, I came across some hurdles. Not impossible to overcome, but not trivial as well.

The Options

There is no one complete solution for developing Flex on Linux. Many folks are looking for one, but there is still none to be found. There are many open source tools that cover vast areas of the ActionScript and SWF world, most of the listed on the wonderful osflash.org. Some of them are just right for you if you have a very specific task (like converting between formats, just compiling a bit of code, etc.), but none provide a complete IDE that lets you both drop in WYSIWYG elements and manually code some stuff, while easily maintaining complete control of what libraries are used.

The Choice

The choice then is to combine as few tools as possible. I have succeeded to get along with 2 tools: Flex Builder Linux Alpha, and Open Dialect.

Flex Builder Linux Alpha is an Adobe free product, which is a Flex build environment as a plugin for Eclipse. Don’t worry about the Alpha part, it seems like a very stable product, and besides eating up some memory, I had no problems with it. It is actually an exact replica of the Flex Builder for Windows, without the features of Design View, some wizards and the profiler.

Open Dialect is the most comprehensive attempt i’ve seen at creating a graphic WYSYWIG IDE for developing Flash. It has some basic characteristics of such an IDE, like a timeline with frames and key frames, and a graphic interface for creating shapes and editing their properties.

The Method

The development cycle is quite simple once you have these two tools running. Use Open Dialect for whatever graphic or animation you need, then grab the code from the “Document Script” tab, paste it to the Flex Builder in Eclipse, and start tweaking whatever is needed, add the MXML code etc. Open Dialect has great potential if it were to enable manual script editing, but currently it doesn’t.

Getting Things To Work

Requirements and Installation of Flex Builder Linux Alpha are covered on Adobe’s release notes. In short, you got to have Eclipse 3.3.x, Sun JRE 1.5.x and Firefox, and just follow the installation instructions there. Be sure to set Eclipse’s browser to Firefox, as mentioned in the release notes, and there are also a couple of guides to walk you through. Oh, and it’s very important to follow these instructions in order for your existing Eclipse plugins to survive the install. I installed the builder and lost my subclipse and collabnet merge plugin, and had to reinstall them.

Open Dialect uses the .NET framework, so you need Mono to run it. According to the installation instruction, you can either download pre-compiled binaries of Open Dialect, or download the source and compile, but then you need MonoDevelop as well. In my case, using apt-get install mono was enough, and Open Dialect ran like a charm.

Tweaking and Real Life Example

Let’s go through an example of how to make a rounded rectangle that gets its color through a FlashVar.

In Open Dialect:

  1. Fire up Open Dialect.
  2. Choose Rounded Rectangle from the Shapes list on the Items pane.
  3. Draw a rounded rectangle on the canvas.
  4. Set its X and Y to 0.
  5. Go to the Document Script tab, select all the code and copy.screenshot-open-dialect

In Eclipse:

  1. Fire up Eclipse, create a new Flex Project, name it “Test”, and go through the creation wizard (next, next, finish).
  2. You are now editing Test.mxml which is a skeleton Flex app file. Paste everything you copied from Open Dialect into Test.mxml, instead of its current content.
  3. Save.
  4. Hey, we’ve got errors! That’s right, BListBox type is not defined. It’s because the script uses the “ActionScriptComponents” library that comes with Open Dialect, in which BListBox is declared, but we haven’t imported it yet, let’s do it.
  5. Copy the directory /path/to/opendialect/ActionScriptComponents to /path/to/workspace/Test/src/
  6. Run again.
  7. Viola! Rounded rectangle showing up!

Now that we’ve covered the basics, let’s see how to pass FlashVars to our app. In order to do so, we need to understand what the Flex Builder environment does in build time — besides compiling the SWF, it also takes the file called index.template.html found in the html-template directory, and compiles it to a file called Test.html in the bin-debug directory, then fires this file in Firefox. So to pass FlashVars and process them in the script:

  1. Open index.template.html
  2. Scroll down to the javascript part under “hasRequestedVersion”, this is the part that runs the swf on our page (assuming we have javascript enabled and the correct version of the flash player).
  3. Under
    "src", "${swf}",

    add

    "FlashVars", "color=0x000000",
  4. Run once to see everything is working, and that we did not screw up the html template.
  5. Add the following variable declaration where all other variable declarations are:
    private var rectColor:Number;
  6. In init(), add the following line at the top of the function:
    rectColor = Application.application.parameters.color;
  7. In the next line, where the shape properties are defined, change the last 2 colors (which in my case were 0x000000,0xFF0000) to rectColor,rectColor:
    RRect1A.Properties[0] = new ShapeProperties(0,0,120,172,"BRoundedRectangle",1,rectColor,rectColor);
  8. Run again, see the rectangle is now black!

Conclusion

The field of Flex development on Linux is of course bound to change as time goes by, but for now it seems like it is still in its early unstable days. This was a brief demonstration of how to harness the IDE power of Open Dialect, and the development and build power of Adobe’s Flex Builder Linux Alpha, to create a working environment for developing Flex apps on Linux. It is by no means the simplest solution — my guess is that running Flex Builder on a Windows VMware could be easier, albeit costly — but this solution that I presented is of course free and conforms to the open source spirit. And, most importantly, can get you developing flex apps quickly and easily.

Have fun flexing!

A Couple of Sidenotes

  • You don’t have to use the ActionScriptComponents library that comes with Open Dialect if you don’t intend to use tweening or frame events. You can use the regular mx.controls classes for just plain drawing.
  • Flex applications tend to be big because the whole framework is included in the build. You can use RSL loading to cache the framework on the client side, or you can make a plain ActionScript Project instead of a Flex Project, still use mxml and just import the needed flash.* libraries. Both of these subjects are out of the scope of this post.

Hardware Failure Apocalypse

I might know a thing or two about handling servers, configs, deployments and cloud architecture. But when it comes to hardware failure on my own workstation, I become a complete layman.

It’s the first time my Lenovo R61 failed me. It’s running a mighty Ubuntu 8.04, with all the components a hacker needs (from a complete LAMP stack, through PDT and a customized version of  svn 1.5.1, to InkScape and xvidcap…), and it’s the first time that after the system froze and I rebooted, I just gazed at the terminal at startup and shrieked:

Kernel panic – not syncing: Attempted to kill init!

And a whole other bunch of error messages, every time at a different stage in the boot sequence. This behavior, combined with the fact that the system just froze and I didn’t do any dramatic changes, makes me think it’s bad RAM or other hardware components (like here, and disk is of course a candidate), but sometimes it seems like people get over it by re-installing a kernel.

I don’t know what I prefer, hardware or software failure. I guess that RAM failure is the best, just swap it with new RAM. Disk failure might mean data loss, which I am sure I don’t want to handle, and recompiling the kernel can be a tedious task, but preferable than losing data and having to re-install the whole system again.

And what I asked myself, when I rode my bike back home today, is “why can’t I just instantiate a new instance in the cloud with the newest working snapshot of my system? Why hardware failure in the cloud is so easy to deal with, and hardware failure in the office isn’t?”. And I had a vision of all the people working on machines similar to mainframe terminals, running only the basic things and having the OS and all the data just sit in the cloud.

This day isn’t far. But tomorrow it’s back to the lab to (hopefully) have my RAM replaced.