Hey,
first of all - some of you may have noticed this is the third AIR related article in two days. I'm very excited at the moment due to the fact I can finally compile them with FDT4. Anyways, I want to store my process and failures, hints and tips to always know where I myself and you of course can find them. So this article now comes a bit more from the designer in me, as it's about chromeless designs. They can be awesome if well thought - and they can be a bit frustrating when setting up the first time. I quickly talk about the following:

• Scaling ain't good, no no
• My misunderstanding of window sizes
• systemChrome and transparent values

Scaling ain't good, no no

The first thing I realised when compiling an AIR with a little design which had to fit: Deactivate content scaling. I've tried 5 minutes to find the exact sizes of the AIR window - but I failed. I just didn't get my design unscaled though it had the same size like my window's area. So I simply set:

into my compiling Class and everything went fine (though the size remained the same - it's really a mysterious thing). If you're going to create a fluid application's design try doing the whole scaling within the RESIZE handler in Actionscript. Don't just let your whole application be scaled - it definetly won't look fine.

My misunderstanding of window sizes

AIR does consider the system based frame as it's window size. So imagine the following:

We design a background image with 505x245px size. We set the SWF compiling size to 505x245 and the Application Descriptor sets "width" to 505 and "height" to 245. We package the AIR file and what happened? The background image is cut at the bottom.

The reason for that is that AIR includes the frame, which every OS is using in it's height properties. As this frame is strongly depending on your system's theme you cannot create an exact-fitting AIR application unless you hide it.

As you can see the Mac OS' frame is included in these 245px height. However, having deactivated the stage scaling the image is just cut. To get the real size of what is visible you can just subtract the stageHeight from the nativeWindow's height. Mac's titlebar (seen left) is 22px height so we would scale our image down to 223px to fit. But obviously this won't work too long as Windows' is approximately twice the high.

So we're in the same trouble we know from webdesign - how to design something that looks well on all resolutions / browser sizes? We have to mix up scaling elements with relative positioned ones. In this case I'd go for a Scale9Rect for the background itself and reposition the text & buttons relative to the window's size to achieve the best looking result.

systemChrome and transparent values

Now comes the funny part - AIR has got a great advantage to native applications. It can be transparent, with own sizechanging (minimize / maximize) & close buttons. We do know this from Mac's Dashboard or Windows7 Widgets. Well designed applications simply fake a titlebar (because users are used to it) and enhance it with application specific buttons and a design. This can work very, very well as we do know from Adobe's products.

By setting these properties you achieve a transparent, frameless application with nativeWindow.height == stage.stageHeight. I love this feature! But you notice users will definetly miss the titlebar so (different to my example) provide a new one.


Besides you have to make your whole application movable by pressing anywhere and drag as your draggable titlebar is missing now. Here are the most used codesnippets you need for minimizing and the like (as put into the click-listener of your new buttons):

Well, I think the next part will be using Linked Libraries in term to go for some animations with TweenLite and FLiNT.