Since the next 360|Flex is fast approaching, I thought I’d post the full recording of my session at the last 360|Flex in Seattle. You can do whatever you want with this video, embed it wherever, watch it wherever, you can even download the original mp4 video file. Hopefully the embedded video is good enough quality to read the code on the screen, if not go ahead and download the full size version, that’s the best quality we got.

At the next 360|Flex at the end of this month in Atlanta I’ll be speaking on “Using Open Source Flex Projects”. If you’ve never been to a 360|Flex event, maybe this video will give you an idea of what they’re like. An important thing to note in this video is that there might be chunks of silence when people in the audience were speaking. I didn’t do the best job of repeating everything people said, but it wasn’t like I could just repeat questions people asked. The session was really a discussion among lots of people in the audience, and it really had a great community vibe to it, with people answering each others questions and teaching me lots of cool stuff. That’s what I love about the 360 events, it’s just a bunch of dorks hanging out and talking shop.

Next Thursday, Februray 7, I’ll be speaking at the Orange County Flex user group about how to use open source Flex code in your own projects. I’ll be covering how to find, download, compile, and use open source as3 libraries, and I’ll be showing off some examples of things you can make without much work by taking advantage of the code that’s already out there. Basically I’ll be talking about how to be lazy and still make cool stuff.

This is a bit of a warm up for my more in depth talk on the same topic at 360|Flex. So the folks in the OC get to be the guinea pigs a bit and help me formulate my 360 presentation. It’s going to be a good time, we’ll hang out, talk about all the cool shit that’s out there that you can use. So if you’re in the southern cali area, come on by next Thursday.

Here are all the important details:

What: OCFlex user group meeting
Date: February 7th
Time: 7pm
Location: FarHeap Solutions offices @ 2601 Main St Suite 1200 : Irvine, Ca 92614

If anyone that’s attending wants to suggest specific open-source libraries they want covered, either leave comments here or shoot me an email.

I just checked the eBay Widget Design Contest rules page again, and was happily surprised to see two important changes to the rules that now make it feasible for Flex developers to enter the contest. You are now allowed to use open-source code licensed under the MIT or BSD licenses, and your widget can be up to 400 kb. Below are the changed portions of the official rules:

Widget may not exceed 400kb in size
…
Widget may not incorporate any open source code except for Adobe Flex under the MPL license, or any open source under MIT or new BSD license in addition to source code published by eBay under CDD license;

Awesome. The wording seems a little odd to me (ahh, lawyers…), but the intent is to allow the Flex SDK, any MIT or new BSD code, and the eBay toolkit code that eBay released under the CDD license. So now you’re free to grab any number of open source projects and use them in your entry. Note that this doesn’t apply to every open-source license (understandably), so make sure you don’t get your hands on anything with those nasty GPL viral licenses. But the MIT inclusion covers a huge library of open-source Flex code that’s out there.

They also raised the file-size limit from 200k to 400k. If you’ve developed Flex apps, you know that you’re not likely to have an app less than 200k. I think 400k is a much more reasonable limit, and opens the door to Flex developers.

I’ve been called out.
So I originally bitched and moaned about how I wasn’t going to enter the eBay widget contest because of the restrictive rules about no open source code. That same day I got an email from someone at eBay, spoke with someone on the phone to explain my issues, and now they’ve gone and changed the rules to be accommodating. I was very impressed with eBay’s concern and willingness to listen to developers. So now I guess I have to enter the contest, right? Unfortunately the truth is I probably won’t get my act together to create an entry, but now the only excuse I have is that I’m too busy. I’m going to try to carve out some time to make an entry, but god knows if that will actually happen. When I originally complained, I was hiding my busyness/laziness behind my rant about the rules. Now eBay has gone and done everything I wanted to make the rules better, and I feel like my bluff has been called.

So to all the Flex developers out there, go win ten grand by making an eBay widget. You can use Flex, you can use whatever cool open source code you can find. You’ve got until February 22 to make some cool shit. A big thanks goes to eBay for being awesome and listening. Thanks guys, you rock.

James Ward already had a little writeup about Mint.com using Flex for some of their spending habit charting stuff, but what’s even cooler to me is that they’re using a few FlexLib components on the site. I got an email from Jason Putorti, a Flex dev with Mint, letting me know that he’s using the DraggableSlider component, and I took a look and also saw that they’re using the ScrollableArrowMenu. Here’s a screenshot of both the components in use:

The menu showing the list of cities there is the ScrollableArrowMenu and above that there’s the DraggableSlider that lets you select the date range you’re using for the chart. Sweet!

Yesterday I made some updates to FlexLib, mostly to sort out some bugs, a few of which I inadvertently created with the previous release. Here’s the list of issues addressed:

• Issue 71: Drop-down tab-list fails to activate when using states with constant names
• Issue 72: SuperTabNavigator -Close Tab-
• Issue 76: Make TabReorderEvent Cancelable/Hookable in SuperTabNavigator
• Issue 77: Tabbar title change does not resize Tabbar
• Issue 78: getChildren in ButtonScrollingCanvas

The first four issues are fixes for SuperTabNavigator issues. #71 and #72 were new bugs I introduced with the .2.2 release without realizing it. My bad. This is what happens when the FlexLib QA team consists of me after about 5 beers. #76 is an added feature for the SuperTabNavigator. #77 is a bug fix for a SuperTabBar bug, and #78 is a fix for ButtonScrollingCanvas for what I guess has been a bug since that component was added.

I also managed to put a up a version .2.3 briefly that had an even better bug with ButtonScrollingCanvas that rendered that component and the SuperTabNavigator inoperable. Woopsies again. I updated the release and the current version (.2.3.1) should have things all sorted out. There were around 250 downloads of the .2.2 release (jesus you people move fast), so if you downloaded that one, make sure to get the latest and update, that .2.3 release is whack.

There’s also a new component dropped into FlexLib, but I’ll blog about that one tomorrow since I haven’t done the writeups for the component description on the wiki pages yet. But it’s in there.

w00t. Keep reporting bugs.

Today I was looking over the details of the eBay Flash/Flex widget contest and thought maybe I’d whip something together and enter. I figured I could probably throw together some eye-candy nonsense using PaperVision, Box2D, fire effects, etc etc and make something that looked impressive. Might be worth a shot at a cool $10k. Then I read the details a little closer and found this clause:

• Widget may not incorporate any open source code except for Adobe Flex under the MPL license;

Fuck that. I use open-source projects in nearly everything I do. Literally everything. This becomes an issue when dealing with consulting work for clients, and I bring this question up right away and ask what kind of restrictions the client wants to place on the use of open source code. On one hand, the client usually wants 100% of the code to belong to them, they want the IP, and using any open-source code in the project is frowned upon. On the other hand I explain the cost of having to build from scratch all the stuff that I can get for free from these open-source projects, and when it starts being thought of in dollars then we usually arrive at an agreement to allow open-source code. Note that this only applies to MIT and other completely open licenses, if it’s not MIT I usually won’t touch it with a ten foot pole.

So eBay wants to run a contest where you can’t use open source code. That means no 3D engines, no physics engines, no custom component libraries. If you wanted 3D you’d have to build your own custom 3D engine. Umm, no thanks. It’s funny because they make the explicit exception for the Flex framework, since if they didn’t do that you wouldn’t be able to make any Flex app at all.

Hell, if you take that clause strictly, you probably can’t even use eBay’s own Flex Toolkit, which is licensed under the Common Development and Distribution License, which is an “open source license based on the Mozilla Public License.” I hope every entry in the contest gets disqualified Come on guys, the Flex SDK is about to be open source, your developer toolkit is open source, and yet you want to say we can’t use open source code?

I want to start off with a quick recap of the current status of the bug I wrote about a few days ago. The Flex 3 Panel bug that resulted in the content of a Panel overlapping the title bar of the Panel has been fixed. The fix will be in the final Flex 3 release. The bug report that shows this status is here: Issue 11279, which is now marked as a resolved bug. I want to point out that I was told (with proof) that Adobe recently started re-investigating this bug on their own about a week before I posted my rant (although that was never exlained in the bug database).

I also want to take a second to address what was seen as me being an asshole with what Matt Chotin called my “strongly worded criticism.” I also received another email from a Flex team member with a similar sentiment letting me know that I may have been a bit harsh and that I need to remember that the engineers working on the framework are good guys trying to do the best job they can for us (the customers). I’ve met Matt personally a few times, and I deeply respect him and all the Adobe engineers working on Flex. I didn’t mean my little rant to come off as a personal attack on anyone, although I realize that since I was targeting a very specific bug that that means it falls under the responsibility of a few individuals. My harshness was a result of frustration and a misunderstanding of Adobe’s perspective, there was never meant to be any direct blame placed on individual engineers. And so with that, here’s my olive branch:

Dear Flex team, I love you all. Your work is greatly appreciated. You make it possible for me and many other people to do work that we love. You’ve delivered a fantastic product and the overall intelligence of the team shows through in the great code base of the Flex SDK. Keep doing your jobs. Even though I may criticize, I mean it with love and respect.

OK, everyone feeling all warm and fuzzy inside? Cool, let’s all get back to work.

Matt Chotin addresses what to do if you run into similar issues like this Panel bug, where you don’t feel the Flex team addressed the issue adequately. He mentions that you will be able to vote on closed bugs in the future, so once that is in place you can still vote on a bug even if it has been marked as NAB, and the Flex team will be able to see which ones have the most community involvement. Until then your options seem to be leaving comments on the closed bug (which in this case meant 4 or 5 independent bug reports of the same issue) and emailing the Flex team, which I think means email Matt, since I can imagine that they don’t want all the engineers dealing with trivial requests from the community all day long.

That said, I’m not sure if I had dealt with the bug differently (ie simply posted a comment and emailed Matt) that it would have gotten fixed so immediately. While I understand that internally Adobe was re-investigating this bug, my hunch is that without the public bitching there would not have been a fix committed for the final Flex 3 release (feel free to correct me if I’m wrong). A single comment on a bug report and an email to Matt likely would have gotten it on the radar (although it already was), but I’m guessing we wouldn’t have seen such immediate action. So perhaps I should have phrased my previous post in a better way, and simply called attention to the bug to try to get others to comment on it so they would reopen. But I think there is certainly a place for publicly posting issues like this, since it’s an effective way to rally the troops and clearly articulate the issue (what was I going to do, write a 2,000 word comment in the bug database?). So in the future I’ll try to be a tiny bit more diplomatic with how I write posts like that.

So thank you Adobe for the quick action in response to this issue.

When Flex 3 was first released in beta you may have noticed a bug having to do with the Panel component when you set borderStyle to anything other than “default” (which funny enough, isn’t even a code-hinted option in Flex Builder). The issue was that the Flex 3 SDK laid out the Panel contents on top of the title bar, so the content ended up overlaid on the title and it would generally look like total crap. Basically if you had a Flex application that used the solid (or inset or outset) borderStyle on Panel to style your application, suddenly when you upgraded to Flex 3 your app looked really bad. Since Alert and TitleWindow extend Panel this affects those components too. You may have seen things in your app that looked like this:

Yeah, that sucks.

So I figured this was one of those bugs that would get reported quickly (it did) and fixed quickly (it did not and will not). There are 4 duplicate reports of this issue in Adobe’s bug tracking system, the first one was reported June 13, 2007. Here are the 4 issue reports:

• Issue 11279
• Issue 12215
• Issue 12872
• Issue 13012

They’re all the same thing, and they each have example screenshots or SWF files that show how bad the resulting bug looks.

The bugs have all been marked as Not a Bug. And this is the explanation for this resolution:

After some back and forth discussion, Glenn and I have decided that Panel will no longer support any borderStyle besides “default”. The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.

Panel will support other borderStyles when using the backwards compatibility flag. In addition, it will be possible to use a combination of explicit heights/widths and absolute positioning to replicate most of the old behavior for alternate borderStyles.

PanelSkin’s implementation of alternate borderStyles will be mostly working, but won’t layout the header and control bar in the correct locations, nor will it size the Panel to be large enough. We need to document these issues.

In the release notes there will be a line that reads:

Release Note: Panel only officially supports the “default” borderStyle. If you use an unsupported borderStyle, use padding values or absolute positioning to place your content in the correct place.

I call bullshit. This is not an acceptable resolution.

Why bullshit? Let me count the ways.

1. You should never be able to make a Panel that has the content overlaid on top of the title bar. That is fundamentally against the definition of what a Panel is. A Panel has a title bar ABOVE the content area. ALWAYS. If the content area overlaps on top of the title bar then something is wrong. If the answer is that Panel will not layout the contents correctly unless the borderStyle is default, then you should not be able to set it to anything other than default (which is not a good resolution either, but at least it wouldn’t produce such crappy looking Panels).
2. This worked very well before, was there ever a single person who complained that the Panel didn’t lay out its contents correctly? It did exactly what it was supposed to do, which is to lay out the content below the title bar.
3. The default Panel skin gets old quickly, and we want to change up the look of the Panel. Used to be that you could just set borderStyle to solid and make some nice looking Panels that didn’t have that same opaque content area with semi-transparent border look. Now those decent looking Panels you styled in your old app are harder to make.
4. I don’t buy the argument that “The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.” I guess the issue is with graphical skins as opposed to programmatic skins. PanelSkin returns border metrics that are used to layout the Panel’s contents (ie place them below the title bar by checking the headerHeight of the Panel). That code seems kinda hacky to me already, it means that the layout of the children in Panel is determined by a programmatic skin. But if PanelSkin is returning the border metrics used in Panel to layout the children then it could easily do so for the other border styles too. This would at least solve the problem when using the default PanelSkin (which must be the bulk of what people do). Maybe I don’t understand the issue with graphical skins, but let’s say you’re using some graphical skin to skin Panel, when would you ever want your Panel to have the content area overlap the title bar? Never. I just don’t get it.
5. The “solution” for people that want to use the “unsupported” border styles is to set the paddingTop style to be the same or greater than your headerHeight, which will force the content to be placed below the header. But wtf kind of solution is that? We have headerHeight for a reason, and that reason is so the content gets placed below headerHeight pixels from the top. This just sounds like an answer of “well, you can hack your way around it, so that’s good enough.”

So basically I’m just bitching, because this bug will likely just stay “resolved” and be released in Flex 3 when it ships with a little release note to warn people to not do what they will invariably try to do. I don’t know if there is a formal thing I should do to try to get someone at Adobe to reconsider, the bug was filed 4 times and all are marked resolved. I assume if I submit a new one it will be marked as a duplicate and resolved. Sigh.

Oh, and Flex for Dummies will have a sentence similar to this:

WARNING: If you set a Panel’s borderStyle style to anything other than default then you must also set the paddingTop style to at least be as many pixels high as your title bar. The default implementation of Panel with borderStyle set to anything other than default sucks.

As I’m doing some writing for the Flex for Dummies book I was digging into the source code for Panel and the other containers. I was writing about how Panel allows you to set the layout property to either absolute, vertical, or horizontal, just like LayoutContainer (or Application, which extends LayoutContainer). My initial thought was that Panel probably just extends LayoutContainer and that’s where we get the layout property from. But then digging in I saw that both LayoutContainer and Panel independently implement the layout property (in basically a cut and paste exact same way). Unless I’m missing something there’s no reason why Panel shouldn’t just extend LayoutContainer. (BTW, for a recent writeup of the LayoutContainer class see Ben Clinkinbeard’s post here).

If you look at the setter for the layout property it’s almost identical in both Panel and LayoutContainer. And take a look in measure() and updateDisplayList() and you’ll see the same calls to layoutObject.measure() and layoutObject.updateDisplayList().

So I dunno, just thought it was interesting. Really I’m just procrastinating while I’m supposed to be writing. OK, back to work…

Ely Greenfield presented some cool ideas about the future of the Flex framework during his presentation at MAX in Chicago last year. The core idea is that they’re considering drastic changes to really apply an MVC approach to the full component set, which would mean the core components themselves would be viewless controls, allowing you to easily apply custom skins and have complete control over the look of each component. I wrote up more about Ely’s session here. The future of these changes is still unknown, I think we’re all hoping that stuff becomes the Flex 4 framework whenever that gets released.

But the Flex community isn’t waiting. There are a number of people working on similar concepts outside of Adobe. A recent post by P.J. Onori triggered this blog post. I’ve noticed a few others working on very similar ideas, so I just wanted to point this out, and make a note that it’s worth keeping tabs on these guys/projects because there’s going to be some seriously cool shit that’s going to be possible.

• P.J. Onori released a set of layout managers. These layout managers are very lightweight, are not tied the Flex framework, and in fact aren’t really even tied to the display of the components. They handle different algorithms for laying out objects, ie in a grid, in a circle, etc etc.
• Stephen Downs (aka Tink) is working on some layout algorithms for use within a ViewStack. The basic idea is very similar, create a set of layout algorithms that determine how the children get placed, but make those algorithms independent of the actual visual component. Tink’s stuff hasn’t been released just yet, but keep an eye out for it soon.
• Ben Stucki is working on an ambitious project he’s calling OpenFlux to create a complete framework for containers, layout algorithms, and component creation techniques. At a minimal level this will allow you to do similar stuff like P.J. Onori’s layout algorithms. But then Ben is going to be combining his stuff with 3D and we’re going to have flexible 3D containers with complex custom layouts (ie you could build CoverFlow using these base classes in a matter of minutes). Ben is calling the OpenFlux + 3D stuff PlexiGlass. In case you saw the session list for 360 Flex in Atlanta and wondered what the hell Ben’s topic meant His session is definitely going to be one to watch at the conference.
• Degrafa has just been released, which allows you to write complex graphics tags using MXML. A core piece of Ely’s presentation relied on the new mx:Graphics tags that are going to be in Flex 4. The Degrafa team has basically done the same thing, but you can use it now instead of waiting for the next Flex release. What this means is that if you have a set of core components without specific visual designs, you can easily create skins using Degrafa in MXML. This idea of MXML skinning and skin-less base components is crucial to what Thermo is going to allow you to do.

So we’re not quite there yet, but we’re getting close. What I’m seeing is that gradually we’re moving toward a highly-customizable, display-agnostic full component set for Flex, coupled with some advanced display options (using both 2D via Degrafa and 3D via PlexiGlass). What would that let you do? You could define a base data-driven list. Then you could choose to render that list as custom 2D graphics using Degrafa, or you could choose to render it as 3D components using PlexiGlass. The underlying component is the same base list component that has a list of data, selectedIndex, etc. But you could swap the rendering at runtime, letting you toggle between 2D and 3D views, or fluidly switch between different 3D layout algorithms, etc.

Some of the stuff I mentioned is released now, some is coming in the next few months. But keep an eye on these projects, they signal a shift in the Flex framework. I suspect that shift will officially come from within Adobe eventually with a future release of the Flex SDK, but it will come from within the community sooner. It’s gonna be fun