You have those times when you get an idea, so you sit down and start building it? You know, maybe you are a designer, and that means cracking up Flash Pro CS5. Or perhaps you are a developer and you start messing with item renderers. As I travel around from conference to conference, I get a lot of ideas like that. And for most of them, I either run out of steam, get distracted, or simply get bored. Over the next several weeks I’ll be dropping projects like that on the old blog – starting with these Flash components that look like Android.
I wanted to get to know Android – intimately. So I started examining the user interface controls. At first this was mostly on the device, to get a feel for the types of controls that were available, and the way they transitioned states. Next I started using the “ddms” screen capture utility that comes with the Android SDK to get a closer look at the pixels. I’d get the screen to a state I wanted, capture it, and then dissect it using Fireworks CS5. Finally, I started reassembling the controls in Flash Pro CS5 and putting ActionScript logic behind them.
The result is a pretty performant, and decent foundation of controls that look and feel like Android, but are done all with Flash, and expected to be deployed using AIR for Android. I could go a lot further with these, but then again, there’s that running out of steam thing. For example, these are really designed for the NexusOne – I don’t account for screen density. I also don’t account for screen orientation, though there’s hooks in the components for some basic sizing.
Okay, enough about what’s not there, what is there?
Some of these components need additional explanation. For example, the “DateChooser”. Most of the dates in Android are presented via a modal dialog box. Mine is no different. Though I don’t call them out as components in the above list, there’s stepper controls used by the dialog to control month, date and year. Likewise for the “TimeChooser” where you will find controls for the hour and minute.
“Footer” is the bar you find at the bottom of most Android forms. The Footer control accepts up to three strings, that will give you up to three buttons. Why three? Well, because that’s the most I saw in use on any Android application. The “Title” is the gray bar you see at the top of most Android forms. The “Menu” takes up to six buttons, and shows up at the bottom of the screen when you use the hard menu button on the device.
Regardless of the component, they are designed to be pretty atomic, and although they were designed in Flash Pro CS5, then can easily be used in Flash Builder 4 from an ActionScript project, because I include a SWC in the build. Here’s some example code, and the result user interface. In short, you instantiate the control you want, position it and size it if necessary, and then add it to the stage. Register for any events you may want to drive the rest of the application at runtime.
package { import flash.display.Sprite; import flash.display.StageScaleMode; import flash.display.StageAlign; import flash.events.MouseEvent; public class Components extends Sprite { private var btn:Button = null; private var chk:CheckBox = null; private var cmb:ComboBox = null; private var day:DatePicker = null; private var ftr:Footer = null; private var lbl:Label = null; private var listing:ListPicker = null; private var opt:OptionPicker = null; private var time:TimePicker = null; private var mnu:Menu = null; private var tme:Button = null; private var ttl:Title = null; private var txt:TextInput = null; public function Components() { super(); init(); } private function init():void { var btnx:Button = null; var lblx:Label = null; var today:String = DateDialog.formatShort( new Date() ); stage.scaleMode = StageScaleMode.NO_SCALE; stage.align = StageAlign.TOP_LEFT; ttl = new Title( "Event details" ); addChild( ttl ); lbl = new Label( "What" ); lbl.x = 9; lbl.y = 52; addChild( lbl ); txt = new TextInput( "Event name" ); txt.x = 9; txt.y = 85; addChild( txt ); lblx = new Label( "From" ); lblx.x = 9; lblx.y = 170; addChild( lblx ); btn = new Button( today, 282, Button.TRIGGER ); btn.x = 14; btn.y = 203; btn.addEventListener( MouseEvent.CLICK, doDateClick ); addChild( btn ); tme = new Button( "1:00pm", 158, Button.TRIGGER ); tme.x = 306; tme.y = 203; tme.addEventListener( MouseEvent.CLICK, doTimeClick ); addChild( tme ); lblx = new Label( "To" ); lblx.x = 9; lblx.y = 276; addChild( lblx ); btnx = new Button( today, 282, Button.TRIGGER ); btnx.x = 14; btnx.y = 309; addChild( btnx ); btnx = new Button( "2:00pm", 158, Button.TRIGGER ); btnx.name = "to"; btnx.x = 306; btnx.y = 309; addChild( btnx ); chk = new CheckBox(); chk.x = 416; chk.y = 396; chk.addEventListener( MouseEvent.CLICK, doCheckClick ); addChild( chk ); cmb = new ComboBox( "Home" ); cmb.x = 13; cmb.y = 487; cmb.addEventListener( MouseEvent.CLICK, doComboClick ); addChild( cmb ); ftr = new Footer( "Done", "Revert" ); ftr.y = 680; addChild( ftr ); mnu = new Menu( [ {path: "search.png", label: "One"}, {path: "search.png", label: "Two"}, {path: "search.png", label: "Three"}, {path: "search.png", label: "Four"}, {path: "search.png", label: "Five"}, {path: "search.png", label: "Six"} ] ); mnu.addEventListener( MenuEvent.CLICK, doMenuClick ); addChild( mnu ); day = new DatePicker(); day.addEventListener( DialogEvent.OK, doDateOk ); day.addEventListener( DialogEvent.CANCEL, doDialogCancel ); addChild( day ); time = new TimePicker(); time.addEventListener( DialogEvent.OK, doTimeOk ); time.addEventListener( DialogEvent.CANCEL, doDialogCancel ); addChild( time ); listing = new ListPicker(); listing.addEventListener( ListEvent.CLICK, doListingClick ); addChild( listing ); } protected function doCheckClick( event:MouseEvent ):void { var btnx:Button = null; if( chk.selected ) { tme.visible = false; btn.setWidth( 450 ); } else { tme.visible = true; btn.setWidth( 282 ); } } protected function doComboClick( event:MouseEvent ):void { listing.show( [ "Default ringtone", "Backroad", "Bell Phone", "Big Easy", "Bird Loop", "Bollywood", "Bus' a Move", "Cairo", "Calypso Steel", "Champagne Edition", "Chimey Phone", "Club Cubano", "Crayon Rock", "Curve Ball Blend", "Dancin Fool", "Digital Phone", "Ding", "Don' Mess Wiv It", "Eastern Sky", "Enter the Nexus", "Ether Shake", "Flutey Phone", "Free Flight", "Funk Y'all", "Gimme Mo' Town", "Glacial Groove", "Growl", "Halfway Home", "Loopy Lounge", "Los Angeles, 2019", "Love FLute", "Medieval Jaunt", "Mildly Alarming", "Nairobi", "Nassau", "No Limits", "Organ Dub", "Paradise Island", "Playa", "Radiation by Spagnola", "Road Trip", "Safari", "Seville", "She's All That", "Silky Way", "Steppin' Out", "Terminated", "Third Eye", "Twirl Away", "World"], "Ringtones" ); } protected function doDialogCancel( event:DialogEvent ):void { trace( "Dialog cancel." ); } protected function doDateClick( event:MouseEvent ):void { day.show( new Date() ); } protected function doDateOk( event:DialogEvent ):void { btn.label = DateDialog.formatShort( day.date ); } protected function doListingClick( event:ListEvent ):void { cmb.label = event.label; } protected function doMenuClick( event:MenuEvent ):void { trace( event.label ); } protected function doTimeClick( event:MouseEvent ):void { time.show( new Date() ); } protected function doTimeOk( event:DialogEvent ):void { tme.label = TimeDialog.formatShort( time.time ); } } }
Again, I want to note that this is a random idea project. It’s pretty modular, but may not be to the liking of many. The package structure is totally flat, though I suppose that’s a nit-pick more than a problem. If you are thinking that I should have skinned Keith Peters’ Minimal Comps, you’re probably right, but I started this on a plane, and it grew from there before Keith’s components could be skinned. All of it is available for download. If you find it useful, or have any questions about the architecture, don’t hesitate to ask.
Kevin Lynch had a Q&A With Brady Forest today at Web 2.0 Expo and addressed a lot of topics including HTML5. As an Adobe employee, I’m kind of excited about what we’ll be able to do with HTML5. Who knows more about drawing APIs and interactive web content than Adobe? Now that HTML5 has started to coalesce a little bit, I think you’ll see us bring a lot of that knowledge to bear as we do build tools that target HTML5. You’ll see some of the early thoughts around that on our Design and Web blog so if you’re interested in that, I encourage you to subscribe.
But just as HTML5 evolves, Flash is going to evolve as well and there are a lot of cool plans for the next generation of the Flash Platform. I think it’s a pretty exciting time to be a web developer no matter which technology you choose.
Editorial
Misdirection is an art practiced by magicians by which an audience’s attention is diverted from one place to another. What’s brilliant about it is that it’s not a lie. Indeed, the audience has to participate for it to work. We, the audience, watch the right hand instead of the left, because what the right hand is doing seems more interesting. The left hand is still there, in plain sight; if anyone bothered to look, they’d see the trick.
After months of obsessive campaigning, Apple scored the final blow with Jobs’ “Thoughts on Flash”. The firm has reduced important debates over open development, censorship on devices, and the future of Web standards into a simplistic dunking booth contest with Flash as the target. Adobe’s CEO called the debate a smokescreen. Adobe has their own biases; they want to direct attention away from the possibility that their flagship product stands to lose market share in the shakeup over the future of the Web. But that’s Adobe and Apple. What matters more is that the rest of the technological sphere has gotten dragged into a pro-Flash, anti-Flash debate. Watching that devolve over the course of yesterday was painful, and it’s time to say something.
It’s a false debate, because it’s clear that Flash’s role in the future isn’t exactly what it was in the past. Flash has traditionally done two things: it’s been a common-denominator solution for video, and a cross-platform development framework for interactivity, animation, gaming, and other “rich” application experiences. It’s recently done those two things in the absence of any solid alternative. In the browser, the bottom line is that open Web standards are finally able to accomplish many if not most of those goals, not only for video but for interactive animation and drawing. That doesn’t mean the end of Flash development: Flash is used for everything from rich client apps outside the browser to animated television on the Cartoon Network. But it does mean a different landscape.
Focusing entirely on that issue, however – as Apple apparently dearly hopes you will do – misses other, more fundamental issues.
The irony here is, I agree with most of what Jobs said — about Flash. (I expect a lot of you are with me.) But this isn’t just about Flash. It’s not just about the iPhone and the iPad (least of which once you start using “the future of the Web” as the catchphrase.) And it’s what Jobs and Apple aren’t saying that bothers me most. Whether the misdirection is intentional or not, whether Jobs’ thoughts are heartfelt (I believe they are), that doesn’t matter. There’s a danger here of losing the plot by allowing Apple to control the whole debate.
There are serious concerns about whether Apple’s path, limiting the tools developers use and what applications can say, is the right course for digital expression. And there are real concerns about the future of video standards, and whether those will give the Internet the freedom with video that it’s had with text, images, and sound. Each of those issues is far deeper than whether or not Flash sucks.
Scoring points against Flash and its issues with reliability and performance is an easy matter. But Apple isn’t just suggesting Flash is a poor alternative. They’re blocking development with other tools, restricting developers from using other tools on their single-vendor store. Apple knows better, developers, what you should do. And Jobs goes further, to argue all cross-platform development libraries, in effect, are bad:
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool.
What does that mean, exactly? When is a “layer” of software “between the platform and the developer”? Jobs’ “Thoughts” still don’t offer an explanation of an issue that has confused and troubled even some of Apple’s most loyal developers. The nearest translation I can work out is that Apple doesn’t like anyone using tools other than their own.
It’s a big deal, too. Complaining about such tools is one thing. But Apple has promised – and delivered on that promise – to weed out even high-quality apps just for the sin of using such tools.
In case there’s any doubt about how sweeping this generalization on cross-platform tools, and how divergent Jobs’ thinking is from actual developer realities, read on:
Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
The problem is, even Apple themselves don’t necessarily live up to the same standard. It took Snow Leopard for Apple to fully “adopt” Cocoa technology in the OS, and Apple’s pro apps have only just become fully Cocoa-based and 64-bit. Aside from illustrating that Jobs is sometimes unencumbered by reality in his arguments, this raises questions about the underlying thesis, that supporting cross-platform development means that you support a lowest common denominator and nothing else.
Incidentally, while its developers have assured me they’re safe, the logic itself flies in the face of even simple tools for artists like OpenFrameworks, which because of how it’s architected as a cross-platform development tool that could target the iPhone alongside a Linux desktop, or any number of other combinations. That’s just the sort of compatibility and portability I would think you’d want for creative expression and development, but the gist of Jobs’ entire rant in “Thoughts on Flash” is the opposite: proprietary, platform-specific development is always better. Apple wants apps on their platform, and not elsewhere. I can’t blame Apple, but I do have to question whether the rest of us need to accept the logic. Jobs is really clear on this point:
Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
Of course, “everyone” wins only if they spend their cash at the Apple ecosystem. And there are casualties: while Apple makes a great case against Flash, they have less of a case against tools like the Scratch viewer, a teaching tool that allows kids to develop on desktops using kid-friendly programming schools and run their creations on the device.
Now, if this only applied to tools, it wouldn’t be so bad. Unfortunately, a topic Jobs doesn’t mention at all is why Apple is blocking certain ideas from its store, too.
Can you say “slippery slope”? Apple’s “Thoughts on Flash” do nothing to explain how the single-vendor control of the iTunes store has apparently made Apple feel responsible for anything delivered on their device. Yes, it’s true, game systems suffer from the same (often worse) restrictions, though I’m not arguing that’s a good idea, either. The issue is drawn into sharp relief because of the number of apps and number of developers on Apple’s mobile platforms – more so as it appears this could be the future of development. (It’s telling to me that Apple is awarding only iPhone and iPad developers its coveted Apple Design Awards this year at the WWDC developer conference.)
Apple already eroded free speech on their platform by blocking pictures of people in bikinis and other PG-rated, suggestive content. As with any censorship, what makes this a dangerously slippery slope is that it mandates double standards. One bikini app is blocked, while another (Sports Illustrated) is fine. [PC World]
Banning bikinis seems overly Puritanical enough. But we were reminded that free speech is at issue this month with the case of Pulitzer Prize-winning political cartoonist Mark Fiore. The very definition of a “slippery slope” is this: once you begin blocking some things, what’s to stop you from seriously impeding free communication. The fact that the browser remains open to any content you like, including hard-core (or potentially even illegal) porn, only illustrates how pointless this whole exercise is.
If application development is important, and not just what’s in the browser, then free expression in applications ought to be important. And as for the one argument Jobs has made on the subject, that “if you want porn, buy an Android,” here’s an experiment for you. Try searching for “porn” or “naked” on the Android Market. I did, to see if in fact Jobs was right and my Droid had become a smutty wasteland. You’ll find almost nothing there. What is there has, most often, one or two stars and a lot of negative reviews. In other words, democracy wins.
So, Jobs didn’t address the fundamental issues of how development works on his company’s devices. But he did score some points against Flash in the “open” battle over the Web and video, right?
The problem is, he didn’t really address the ongoing concerns about H.264, and the reason everyone hasn’t already adopted the video tag with that codec as a standard.
Web tags aren’t really open unless there’s a standard underneath for them to serve. Early standards advocates learned this the hard way with GIF, the Graphics Interchange Format. The story goes like this: for years, GIF was adopted as a graphics encoding standard online. Sure, it was patent-encumbered and could potentially result in massive license fees – but it was free at the moment, so why should anyone worry? (Is this sounding familiar yet?) In the late 80s and early 90s, GIF was a free ride, so no one bothered to adopt an open alternative. Then, just as GIF began to peak in popularity, the folks who owned the patented technology, UNISYS, decided to change the rules. It was their right to do that, because they still owned the patent.
Ironically, GIF’s patent was far less dangerous than the patent that covers H.264, because it applied only to the LZW compression algorithm used in writing the files, not decoding them. That meant only the GIF creation tools were really at risk, from 1994 when the additional fees were announced to 2004 when the patent expired. (If you want to brush up, there’s a 2004 reprint of a 1995 story on the topic.
First, it’s important to understand that MPEG LA, the body that licenses H.264/AVC (among other things), represents not one patent owner but a pool of patent owners. Those owners set the license fees and terms. That makes licensing patented technologies easier, but as far as making H.264 the new video standard for the Web, the whole situation is more complex, not less – because any member of that pool could decide to cause trouble before the patents expire, in roughly 2025.
But I digress. There’s a bottom-line question here.
Is it possible browsers, streamers/broadcasters, and users might incur license fees for using H.264? If they did, it could threaten the freedom of video on the Web in generally, which depends on a level playing field for publishers and viewers. It could also be devastating to free and open source video production tools: not only would those tools violate the patents, but it’s possible users of those tools could be liable for fees.
The answer is relatively clear, but only through New Years’ Eve at the end of 2015. From Betanews:
As part of its response late yesterday, MPEG LA delivered a statement to multiple sources, including Betanews, announcing that the rights management firm will extend the period for which it will refrain from collecting royalties for use of H.264 in free streaming video, until the last day of 2015. The term of that royalty-free agreement was due to expire at the end of this year.
“Products and services other than Internet Broadcast AVC Video,” reads MPEG LA’s statement to Betanews, “continue to be royalty-bearing, and royalties to apply during the next term will be announced before the end of 2010.” Internet Broadcast AVC Video is the name of the patent portfolio to which H.264 belongs, when used in the context of streaming.
H.264 licensing body won’t charge royalties for HTML5, other Web streams [Betanews, February 2, 2010]
That’s an incomplete answer, though. We still haven’t seen the 2016-2025 terms, and just as importantly, the MPEG LA is very clear that users could be liable for the use of the codec. From the same article:
But in a direct, personal response to the LWN.net reader that was shared with other members, MPEG LA global licensing director Allen Harkness explained that the fact it doesn’t charge end users (viewers) royalties for downloading H.264 streams, doesn’t mean they should not be licensed to do so. Effectively, someone has to be licensed to produce the videos, and that license does incur a fee. But that license is then effectively passed downstream to the end user.
“While our Licenses are not concluded by End Users, anyone in the product chain has liability if an end product is unlicensed,” wrote Harkness. “Therefore, a royalty paid for an end product by the end product supplier would render the product licensed in the hands of the End User, but where a royalty has not been paid, such a product remains unlicensed and any downstream users/distributors would have liability. Therefore, we suggest that all End Users deal with products only from licensed suppliers.”
By the way, before you get your conspiracy theorist hats on, one of the companies that could wind up paying steep fees is Apple. Apple is just one member in the MPEG LA pool, and its liability (the number of patents for which it would have to pay) could well be greater than its equity (the patents Apple themselves own, which are far fewer in number and smaller in importance). It’s more likely that Apple’s support for H.264 is motivated by practicality, not some desire to cash in on H.264 patents. They’re already paying to be a licensee, and they’re aware of the legal ramifications of using H.264. It’s “the devil you know,” in other words.
There are many things to like (or even love) about H.264 as a codec, but it’s a stretch to argue that H.264 is the best codec for all Web video.
On this, we can ask Adobe and get a more fair and balanced answer. Adobe added H.264 support in Flash Player 9 and Adobe AIR. If it was the solution to everything, you’d expect it would have been the solution in Flash. So why wasn’t it? David Hassoun of RealEyes Media explained in a Flash 9 tutorial on the Adobe Developer Connection:
So does this new Flash Player support for MPEG-4 and H.264 mean that it will replace the On2 VP6 codec? Absolutely not. The addition of H.264 gives developers greater choice to select the technology that best meets their needs. The current implementation of H.264 does have some limitations, such as lack of support for alpha channel and the inability to embed video into a SWF file. On2 VP6 is a solid, high-quality choice for Flash-based video projects. The On2 VP6 codec is also clear of any licensing issues that may arise with MPEG-LA. (Licensing information can be found on the MPEG LA and Via Licensing sites.) The On2 VP6 codec will remain a consistent and viable option for media delivery—see the On2 VP6 technology white paper (PDF, 140K) for more information. The added support for H.264 simply means that there are now more options and wider spread compatibility for high quality and HD video.
Apologies for my geeky Empire Strikes Back metaphor, but here’s where we’re at: OGG Theora is blasting into space, headed for a losing battle with Darth Vader. “That boy is our last hope,” says the open video movement. “No,” says Yoda, or, erm… maybe Google. Or me. Or Frank Oz. Or something. “There is another.”
If Google were to open up the video codecs it got from On2, the whole debate could change, as I wrote last week. On2’s video codecs may actually, ironically, be better suited to the job than H.264, for some of the reasons above. But most importantly, it would mean that On2 video could become a format that’d satisfy the major browsers and open and proprietary video production tools alike, without everyone risking incurring lots of fees. (One variable to explore would be this codec’s performance on mobile, though I know various parties have considered On2’s stuff as a mechanism for targeting mobile devices.)
But let me be clear: this is not just me wishing I’d gotten a job with ZDNet or going off on some personal vendetta. There are major reasons for the visualist community to care. Both this site and its sister site have long been about online freedom of expression, and about the democratic power of our connected world and its open standards. If we’re going to have the freedom to edit, produce, distribute, and consume video, having proprietary “taxes” along the way is a very bad thing. And this debate isn’t over yet. It also has far, far less to do with Flash than a lot of people currently seem to think.
Right now, though, the news isn’t good. The biggest news this week was largely ignored:
I’m not optimistic. If I had to bet right now, I’d bet on a patent-encumbered future for video. When I spoke to parties from organizations like the Mozilla Foundation at the Open Video Conference, their biggest concern was time. While the world has focused on Apple and the iPad, the simple truth of the matter is that everyone in the tech world has reached a consensus that the time for video directly in the browser, as part of HTML5, is now. So what everyone has been waiting for is support from the world’s leading desktop OS vendor and #1 browser maker: Microsoft.
I think the battle is over. Dean Hachamovitch, General Manager, Internet Explorer says that Microsoft has chosen H.264:
H.264 is an industry standard, with broad and strong hardware support. Because of this standardization, you can easily take what you record on a typical consumer video camera, put it on the web, and have it play in a web browser on any operating system or device with H.264 support (e.g. a PC with Windows 7). Recently, we publicly showed IE9 playing H.264-encoded video from YouTube. You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here. For all these reasons, we’re focusing our HTML5 video support on H.264.
So why isn’t Microsoft concerned about the litany of potential license issues above? That’s easy: Microsoft doesn’t need open standards. You’ll need to pay for that license somehow. So why not get locked into their proprietary operating system in the process?
Other codecs often come up in these discussions. The distinction between the availability of source code and the ownership of the intellectual property in that available source code is critical. Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.
In fact, Microsoft is better off if alternative operating systems like Linux and Android incur license fees. It means those operating systems are just a little less free, which erases some of their advantage over Windows.
Is there any hope at all? As near as I can figure, Google is now the only company with the leverage to navigate us out of this mess, thanks to the enormous popularity of YouTube and the growing popularity of Android and the Chrome Browser, plus the fact that Chrome OS is on the horizon. Time is running out, but if (this is a huge if) Google were to open up an On2 codec, then adopt it across YouTube and its mobile and browser lines, then nail implementation so well that it convinced others (particularly Microsoft) to follow. The other likelihood is that even the likes of Microsoft may privately adopt a “wait and see” approach with those MPEG LA terms. If later this year, MPEG LA either plans to hike its rates in 2016, or it doesn’t cover terms all the way to 2025, it might raise the appeal of an alternative like Google’s.
Alternatively, we can hope that the MPEG LA decide to be generous and extend free terms through 2025. If that happened, then even this patent-encumbered video format could become a major tool in the open Web. We’d effectively get the dreamworld Apple has been hinting at: an open video tag with a free video format that looks great and has wide hardware and software support. So the “happy ending”
doesn’t have to exclude H.264.
Mozilla is, in the meantime, in a tough position. Having promised not to support H.264, we could wind up in the weird situation of having to use Flash in Firefox while Chrome, Safari, and Internet Explorer all use HTML5 and H.264. It seems that could change, though, depending on how things play out. The fact that Mozilla has taken the hard line ought to suggest that there is at least some cause for concern.
Phew. There’s absolutely no way to cover this issue in a small number of words. Well, or you could gloss over the issues and pretend they don’t exist, if you’re a tech CEO.
There are other issues left out of Jobs’ “thoughts,” though.
Don’t get me wrong. As I said, Jobs’ “Thoughts on Flash” likely mirror a lot of our own. What I’m saying is that we don’t have to limit our thoughts to that debate.
Cross-platform development, freedom of speech in software, video codecs, patents, intellectual-property, Web standards: these are all complex issues. They merit more than simply scoring quick political points against one platform or another. (And yes, that includes even being too quick to dismiss Apple’s platforms and what they do right.)
This isn’t just about the iPad or the iPhone. It isn’t just about Apple. It’s about which debates we have, who frames them, and how we address them.
The point is, what we all see in our Web browsers could depend on the these issues. What the tech community thinks and decides about how development should work, about which freedoms are important for developers and which aren’t, all depend on these issues.
Mesmerizing magic tricks are a good time. But in this case, the responsibility falls on us – not Apple, on us. Fool me once…
Scaleform has announced that Scaleform GFx, their Flash-based solution for graphical user interfaces for games, is set to be included free of charge with the Unreal engine.
They’ve made a nice video of the thing in action, going all the way from the Flash IDE to a new menu and interface for Unreal Tournament III. The video brought a smile to my face — try to find out why:
The funny thing? I don’t remember whether I’ve said this publicly before, but Tweener was initially planned as an UnrealScript extension – I needed some tweening extension for a project I was working at the time (the UI for the Defence Alliance 2 mod for Unreal Tournament 2004), and a MC Tween-like syntax wouldn’t work. In the end I dropped the idea since I would have not enough time to complete it for the mod, and instead took it over for AS2/AS3 a little bit later. It’s super nice seeing it going all the way around and finally being used in the game by way of Scaleform GFx – I don’t think game UI systems have anything nearly as practical as the tweening concepts Actionscript has had for a few years.
Of course, any other tweening extension will probably work within Scaleform GFx, so it’s not like Tweener is any kind of bundle; it was merely what they were using in their example.
We have finally released the first version of the Audiotool. I am very thankful for all the kind tweets and happy that our work is now available to the public.
However the current version is named Firestarter for a reason. What you see online is just the tip of the iceberg. I can not wait to start implementing all the cool features that will separate us from traditional software ;)
