Sure, I find too interesting to have [quote=“MagicLord, post:20, topic:2756”]
UI properties driven by timeline animation
[/quote] and this could be done through logic nodes too.
I also appreciate too a lot the capabilities given by Zui and it would be great to have it integreated too into a Armory UI Editor.
but actually before “Investigate UI system which allows easier styling for components”, it seems to me that there isn’t too much work to do to get the actual UI Editor usable … considering that it actually takes care only the elements of type 0, 1 and 2 (Text, Button, Image) which isn’t sufficient, but a good start … and this without addressing the lack of logic nodes, even if I think it’s a great advantage for Armory to be preserved at all costs.
Maybe too that the need for customization/style could be obtained directly and as soon as possible by allowing us to set those things directly into the json file as a first step, before having the perfect tool UI Editor to do it in the futur Armory 1.0 (with zui inside too) ?
You see what you get, no need to create traits and connect nodes.
I don’t ask for that feature, i’m just pointing how great it is.
Not sure it’s doable, but timeline driving objects or materials properties could be a very interesting feature.
It’s not about the perfect UI, but choose the best UI for long term.
For example UI could be multi threaded and propose tweakable refresh rate.
So it’s not only about UI button, image and text LOL
What you ask is a custom temporary solution, why not using a work around ?
Keys to simulate UI buttons and textures on flat polygon camera aligned for UI images and text.
My advice is use a commercial engine if you have something commercial needing UI in big hurry.
Armory is alpha, it should not be rushed but get features more stable working as expected.
@MagicLord On my side no hurry or infeasibility… everything is easily programmed with Armory thanks to Lubos.
Saint-Exupéry said it most eloquently, : “Quant à l’avenir, votre tâche n’est pas de le prévoir, mais de le rendre possible” (Le Petit Prince) " As for the future, your task is not to foresee it, but to enable it "
@Didier The biggest reason that I think that going with something other than trying to improve Zui for use in Armory games, is that getting Zui to the point that another UI system is already at, will take more time than it would to integrate Armory with an existing UI system that already does it.
Zui is pretty set in the way it looks ( I’m pretty sure you can only change colors ), and even if you made the UI editor work, you would still have to do more engineering to make extra elements like text areas, and make them style-able so that you could make them look right in the context of your game.
The time that would have been spent developing Zui and the editor for those features, could be more efficiently spent writing the glue code for an integration with a UI system that already has text-areas, styling, and an editor like HaxeUI ( granted, HaxeUI still needs work of its own, too, but it is still further along that Zui ). Also, we can just as easily make nodes for that UI system as we could for Zui.
It is a matter of wanting to most efficiently spend our time. We don’t want to spend a lot of time on Zui, if it would be more efficient to go elsewhere. Depending on how much work it takes to do the integration, we could potentially land a lot more features for the UI faster.
I fully agree with @zicklag that it is not good to waste time if there is an off-the-shelf solution that can be quickly integrated into Armory.
Whatever the design tool of tomorrow’s UI on Armory, however, there are a few things that I think should remain constant, such as the fact that all interfaces, both for the designer and for a gamer itself, focus on the user’s needs and objectives and make them as transparent and as easy to adopt as possible.
Then I think we share the need too that performance and cross-platform portability are respected as we have with Armory/Haxe today, thus that we don’t want lack of integration between platforms, editors, langages … as having multiple disparate systems requires more training and time for adoption.
Thus I think that you share with me too that we don’t need investing efforts in a 3D game engine system for where we are now, but for where we want all to be, and I think that @MagicLord is ready to remind it to us, and @Lubos perfectly aware of that.
… and this without addressing the lack of logic nodes, even if I think it’s a great advantage for Armory to be preserved at all costs.
thanks to Lubos.
so do it LOL