Archive | May, 2009

What did I do the last year

26 May09

I just delivered yet another Away3D project for a longtime client of mine - dna shoes. It’s a nice competition for Converse shoes that use MMS and email to build a nice 3D gallery (based on one of my workshop files). I’ve done lot’s of Flash 3D this year and it’s actually become my main income the last 12 months.

For many years, I’ve used Blinksale for my billing purposes. It’s a very basic service, but it does have one neat feature and that’s tagging. By selecting invoices by tags, I can easily see what I spent my time on and Flash 3D is a BIG part of it. This chart shows what kind of projects I’ve billed the last 12 months:
whatdidIdo.png
This is just my commercial work and in addition I’ve also done many personal projects. Most of these include Away3D in some way so if anyone ever wondered if it’s possible to make money from Open Source Flash - here’s another little bit of proof. Thanks to the entire Away3D team for filling my days (and nights) with fun!

PS: The 6% training is also Away3D! :-D

Realtime 3D on the web - a toy or a useful tool?

22 May09

A little late, but here’s the slides from my presentation at the FlashForum Konference in Cologne. In the session, I discussed 3D on the web and what it’s good for. I started with a historical overview for we’ve had 3D on the web for a long time already. It’s never been a success though and I highlighted some possible reasons as well as why Flash changes this. I also tried to draw up some rules for what constitutes “good use of 3D on the web”. Is showed no code at all in the presentation and the slides don’t give away all I said, but you’ll get the idea.

PDF of presentation

I’ve done lots of presentations before, but this was the first time I presented at an international conference in English. I was super-nervous but the session went really well and I got some good feedback. It kind of surprised me how little feedback you get initially. Just a few mentions on Twitter that said my session was “nice” - not all that encouraging. Later I got the feedback from the Feedback forms as well as blog articles such as this one that said “Fantastischer Vortrag und super Redner”. Really strange to not just give feedback like I usually do on Flashmagazine, but also receive it! :D

jensaAtFfk09.jpg
Photo by Marc Thiele/FFK

The day before the conference, I also did a full-day Away3D workshop. Renowned community expert Peter Elst was there and I’m glad he enjoyed it! I also did two reports from the event for Flashmagazine.

I have to congratulate Marc and Sascha - they really know how to pull off such an event! The mood was excellent. 500 attendees, 28 sessions, 10 workshops and not a glitch. Pretty neat and all served at a fraction of the cost of other conferences? Pretty impressive if you ask me! I had a great time!

AIR window resize inconsistencies

14 May09

The last two weeks I’ve been working on 3 different AIR apps and I have to say I really like Adobe AIR. It’s easy to develop for and quite consistent across the various Operating Systems. One thing that had me (and others) puzzled is how the windowing system works, so I thought I’d add a post for future reference.

There’s two main ways you control the appearance of the main application window. One is by setting properties on the mx:WindowedApplication tag and the other is to set properties in the application.xml file that defines each AIR app.

Resizing

The application.xml has a xml property that controls the resizing of your app:

<!-- Whether the user can resize the window. Optional. Default true. -->
<resizable>false</resizable>


So to prevent resizing, you just set this parameter to false, right? Not right. You will notice that the “gripper” is still present in the lower, right corner of your app and this allows rescaling. To turn off the gripper, just add showGripper=“false” to your WindowedApplication tag and that’s it. Or is it? Of course not. To make this work with the system chrome, you’ll actually have to turn off the Maximize button as well, making the complete settings like this:

<!-- The type of system chrome to use (either "standard" or "none"). Optional. Default standard. -->
<systemChrome>standard</systemChrome>
<!-- Whether the window is transparent. Only applicable when systemChrome is none. Optional. Default false. -->
<transparent>false</transparent>
<!-- Whether the window is initially visible. Optional. Default false. -->
<!-- <visible></visible> -->
<!-- Whether the user can minimize the window. Optional. Default true. -->
<!-- <minimizable>false</minimizable> -->
<!-- Whether the user can maximize the window. Optional. Default true. -->
<maximizable>false</maximizable>
<!-- Whether the user can resize the window. Optional. Default true. -->
<resizable>false</resizable>

The other option is to not use the operating system’s windowing style, but rather the standard one that AIR provides.

<!-- The type of system chrome to use (either "standard" or "none"). Optional. Default standard. -->
<systemChrome>none</systemChrome>
<!-- Whether the window is transparent. Only applicable when systemChrome is none. Optional. Default false. -->
<transparent>true<transparent>


These settings will automatically hone the

setting specified in the XML, so the window can’t be resized. You’ll still see the “gripper”, but it won’t have any effect and you can easily turn it off.

The Fullscreen bug

Another, slightly related thing you should be aware of is that there’s a bug relating to using standard window chrome and setting the

/

properties in the application.xml. If you turn off these properties, they will be grayed out (disabled). Once you set the app to FullScreen mode and return from it, the maximize/minimize buttons are now incorrectly set as enabled allowing the user to set them. Only workaround I know of is to loose the OS native window chrome.

It would be great if this was cleaned up and made more consistent for the next iteration of the AIR runtime. If I turn off the gripper, I want it to disappear (no matter what) and if I set resizable to false, I actually don’t want it to be possible to resize the app, no matter what.

I’d also love to be able set properties such as “Application.application.maximizable” at runtime so I don’t need the XML file at all. It’s really just annoying and messing up my development process.

Note: This post applies to AIR 1.5. I’m not sure, but I think this applies to NativeWindows as well.
airLogo.jpg

How to shoot yourself in the foot

13 May09

Twitter has become an important part of my day, but today it lost a lot of it’s value to me. By changing this ‘tiny’ setting, I no longer see the conversations that my friends have. I only see people twittering for themselves or directly mentioning me. I now get only 1/6th of the messages I used to get.

This is not how I use Twitter. I use Twitter to follow what my colleagues in the community and friends do and chat about. By removing this feature, the value of Twitter is now VERY reduced and I feel like quoting Eivind Ingebrigtsen that tweeted last week: “Assumption is the mother of all fuck ups. If you assume, you’ll make an ASS of U & ME”. By ASSuMing things like this - Twitter could easily kill itself… You’ll find some good commentary on this topic at the Ajax Blog as well.

assume.jpg