Just a quick update to let everyone know that the beta.1 preview build of Feathers UI is now available on Haxelib. For those who might not know about the project yet, Feathers UI is an open source UI component framework for cross-platform development. It’s built with Haxe and OpenFL, and it can target mobile, desktop, and web.
We’re now leaving the alpha stage to enter beta, and the core architecture is looking really solid. Breaking changes should be minimal going forward, and most of the components that existed in the Starling version are up and running in OpenFL (plus a few extras that never existed in Starling at all!).
Today’s beta.1 release includes new Drawer, HDividedBox, VDividedBox, and LayoutGroupItemRenderer components. A new ResponsiveGridLayout makes it possible to tweak the layout of a single view on multiple screen sizes, and three new samples demonstrate how to create custom programmatic skins.
For complete details, see the official beta.1 announcement on the blog:
From the Kickstarter backers, to the early adopters using the alpha builds, to everyone who has provided feedback over the years, thank you for this opportunity to continue developing Feathers UI and making it even better.
It seems that I accidentally made beta.1 incompatible with the older OpenFL 8.9. That was a mistake. I know that not everyone is ready to upgrade to OpenFL 9 yet. It’s fixed on Github, and I’ve updated the CI server to build with 8.9 so that it doesn’t happen again. I plan to release beta.2 soon. Probably within the next two weeks.
Feathers are really super cool.
I used them for production released projects with flash Starling.
However 2 things currently making me think twice to use them for now:
Fully support of creating components via xml mark up. I cannot say, that it MUST be, because with Starling I’ve created all the feathers stuff via code and it was fine.
Support different backends like HaxeUI. Not only Openfl.
2nd is very important in my opinion. Currently I’m planning a development of new big project.
There will be 2 client sides. One is 2D for game administrators and moderators with simplified view and extended interface. And the second client is fully 3D.
For 3D I almost decided to choose Heaps.
For 2D I am still thinking. I really love Feathers and have a big experience with it. But I won’t be able to share Feathers components with 3D client, what is sad for me.
I am also not sure to choose HaxeUI, because IMHO it is buggy and haxeui-heaps doesn’t work nice on mobile devices.
Heaps has it’s own ui system called DomKit. But there are a lack of components I can use and extend. Almost everything should be done from scratch.
So I am still in a think process
Anyways, thank you very much for the great job you are doing.
A declarative XML format is definitely in my future plans, at some point after the first stable 1.0 release. If I could work on Feathers UI full time, I’d have been trying to get XML done sooner, but since I have limited time, I need to focus on the core components right now.
The reason Feathers UI targets OpenFL is because I can continue to use the classic Flash APIs that I’ve come to love over the last 15-20 years. I’m not going to abstract Feathers UI so much that you can’t just addChild() them in a Sprite or MovieClip anymore. With that in mind, any hypothetical new “backends” that I were to consider adding in the future would need to clearly be inspired by the Flash display list and event architecture.
For instance, I could hypothetically consider targeting Starling again (Note: To be very clear, I’m not saying that Starling is on the roadmap here.). Most of the APIs are the same because Starling was designed that way. The hardest part would be reworking things for Starling’s different mouse/touch events and to create appropriate skins (since Starling relies more heavily heavily on textures). In the end, though, the vast majority of the code would be shared.
Anything that diverges further than Starling does from the classic Flash API is extremely unlikely. Basically, I need to be able to have one codebase with some conditional compilation that is limited to a small number of critical differences between libraries (I would also consider a branch/fork, but again, the differences should be minor enough that most merges would be clean and easy). In the end, I want the components to feel native to whichever library they are targeting, whether it’s OpenFL, Starling, or something else with a similar API.
