baturinsky:
The way Defold is built and the way it try to solve things is to only provide small building blocks so everyone can build up their own libraries. this is really intentional and in my opinion the only way to go. Being experienced in quite a few engines I know for a fact that it doesn’t really matter how many tools and solutions you put in there, there will always be something missing or something not really behaving the way you want it to behave.
Even if you would get eg. a button feature, a user would like the button to animate when clicked instead of changing image. Or both. And have sound. And have a function connected to it. Or not. It would be autoremoved when clicked. And state saved. Or not. It would actually have two functions tied to it being toggled.
Etc…
Instead of supporting all cases is better to give tools so the developer can create it him/herself. That’s where an engine could shine (or not).
Having features like a gui table would raise multiple time more usercases and questions than the button one and every user would like to have it behave in different ways when scaling, adding sprites in the table, visible 99-sliced borders etc etc.
I’m just trying to explain that it is sometimes not a good thing to make an engine bulky with millions of features that still maybe don’t even fit your purposes and you end up writing your own in the end. I say, focus on good small building blocks and develop whatever tools you need for your game. That is the design of Defold.
But as Sicher says. If Defold focus on giving us a lot of good basic tools there is a good chance that the community builds great gui libraries that solves some basic things like a buttons, scrollbars or even images within text.
