Recently, Josh Tynjala announced a new version of Feathers UI for OpenFL and Haxe and its Kickstarter campaign. Have any questions? Maybe they've already been answered below!
Feathers UI is an open source, cross-platform library of user interface components for creative projects. It is especially well-suited for games, interactive visualizations, and other rich, multimedia experiences. With Feathers, you can create apps for a wide range of devices, including phones, tablets and desktop computers.
Feathers UI was originally developed using the ActionScript 3 programming language with the Adobe AIR runtime and Starling.
Yes! Feathers UI will use the same MIT license as OpenFL.
The source code is available now on Github! This project is still in the early stages of development, and it should be considered unstable. It's probably best to avoid using it in production at this time.
Yes, Haxe is open source.
Yes, OpenFL is open source.
No. This new version of Feathers UI will be built directly on OpenFL. That's one less dependency to worry about!
Yes. In fact, you'll gain access to more platforms. Similar to Adobe AIR, you can build apps for Android, iOS, macOS, and Windows. Additionally, OpenFL and Haxe also give you access to web browsers (no plugins required), Linux, and game consoles.
Kickstarter. Visit the project page to add your support as a backer.
Tuesday, June 25, 2019 at 8:00 AM US-Pacific time (GMT-7).
Thursday, July 25, 2019 at 6:00 PM US-Pacific time (GMT-7).
Check out the Feathers UI rewards on Kickstarter.
Go here to sign up for updates, and you'll get important announcements about the Kickstarter campaign, development milestones, and more — sent directly to your inbox.
Yes. Some components and properties will have slightly different names
in the new OpenFL version, if the names can be made clearer or more
concise. For example,
StackScreenNavigator will be
StackNavigator. Properties like
isSelected will be simplified
Additionally, some existing API names would conflict with classes or
methods in the Haxe standard library or in OpenFL. For instance, Haxe
has a built-in data structure named
List, so the Feathers
List component will become
Similarly, display objects in OpenFL already have an
invalidate() method, so Feathers UI components will use
setInvalid() instead. In these cases, there's no choice
but to change the name in Feathers UI to prevent collisions.
By the time that version 1.0 is released, a migration guide will be available to help you find any new or renamed APIs.
An automated tool like as3hx can certainly be helpful when porting an existing ActionScript codebase to Haxe. It may be able to handle 70-80% of the conversion for you. However, it's likely that you'll need to tweak some of the code generated by as3hx before everything will work properly.
Haxe and ActionScript are very similar languages, but sometimes, they don't behave in exactly the same way. Even if your existing app didn't use libraries like Starling and Feathers UI, you would probably still need to tweak the generated code a little bit, depending on which ActionScript features you were originally using.
Additionally, while OpenFL and Starling were both inspired the display list and event model of Adobe Flash Player, Starling's API diverges a bit more from the original because Starling provides more control over the GPU and managing textures. As a result, some APIs that you used in Starling may not exist or may not work exactly the same in OpenFL. Usually, there is a similar API that you can use instead, and sometimes, you can rely on the fact that OpenFL manages some things automatically that Starling did not.
Finally, this new version of Feathers UI will include some of its own API name changes. See the previous answer for more details.
Not at first, but it's definitely an important feature to me, and I want to add it as soon as possible.
As you may recall, supporting MXML with Feathers UI for Starling required forking the Apache Flex compiler. Haxe has a powerful, built-in language feature called macros that allows developers to hook into the Haxe compilation process. It should be possible to use macros to support a declarative file format similar to MXML at compile-time (without forking the Haxe compiler). Additionally, I'd like to look into ways to dynamically load UI using a declarative file format at runtime too.
Developers will be able to purchase premium components that aren't included for free in the core open source Feathers UI library. For example, some projects may need charts/graphs and other data visualization components. These types of advanced components may be too complex to justify the time and effort for a single developer or a small team to build them from scratch.
At the same time, the extra maintenance required by their complexity — along with their smaller target audience — makes adding them to the core Feathers UI open source library somewhat hard to justify. However, by providing an open core with premium add-ons, Feathers UI can offer a wider variety of components for developers who need them.
Additionally, premium components make it easier for the community to support Feathers UI financially. To put it another way, you can probably convince your boss to make a purchase that helps you get your work done faster, but it's more difficult to get approval to donate to a project that anyone can download for free. These premium components create a source of revenue that helps to ensure ongoing development of the core, open source library.
No! You can certainly expect to see new open source components in future updates to Feathers UI.
Yes. You will receive the complete source code for the component.
All premium components will include written tutorials, an API reference, and one or more example projects.