Some thoughts and input on it.
I played around with it quite a bit tonight to see how far I could get with it as a GUI tool.
First thing is it likes to interfere with mouse inputs. For example if you try using it on the top down example / demo. You first have to tell the canvas to not be enabled, which really limits your options beyond overlay type setup. You also end up with things like on mouse down don’t fire constantly, or they do but the canvas blocks or captures. So either I’m missing something or it really makes things like top down game setup where you are doing on cursor hit type things, a royal pain cause it’s trying to hit the UMG elements.
Second, would prefer option for it to be percentage based. I made a function that allows me to position everything based off screen percentages. Similar to how CSS lets you do it with webpages, so instead of pixel driven. I can tell the element to be 3% from the left of the screen and 10% down from the top. It also does sizing same way with minimal size to prevent things from getting too small. This allows for the GUI to scale to any play window real time while keeping it’s aspects the same. It also passes out the resulting size dimensions and locations so you can use them as a container for other elements. So I can have a health bar background that takes up 40% of the screen horizontally, then have a healthbar that is driven off player health fill that bar so when the player is at full health it’s 100% of health bar background, as they go down in health it’s taking less of the background up. However since it’s told to be within the dimensions of the healthbar background as it’s “container” it shrinks as it should if the user changes their play area size. Works great but ends up with a ton of annoying blueprints and lines getting dragged all over the place to feed the data between the functions. Having the option for percentage base resolves the problem of dealing with set resolutions and interpolating between them, allows users to change their screen size or play window as they want, so say they want to make it an odd size to allow for them to read skype etc they can realtime with no problems. There are a few small downsides of the players going super ultra large or going super small. Here is link to a video with the percentage based UI. https://youtube.com/watch?v=45GPp9UFdeg
It’s also really powerful in regards to driving things like health bars, allows for smart inventory slots, and much more.
As far as element options and things to be allowed with it. A tabbed window, basically what you see often in chat boxes, where you click on a tab and it changes you to what basically is a different dynamic text box. We can make it with the current elements but having it more “preconfigured” would be nice. So drag tabbed window into the editor, for properties it has elements that represent each tab, that then create titles for the tabs, and an panel that can then get whatever is needed. Like I said we can make it now but it’s clunky making it put together would be nice. Similar thing with the slots, it works but it’s really clunky to use, prefer to just drag slots into editor then add elements to it, then have options for which way the elements fill.
It’s probably possible with the current setup but having mouse over on an element spawn the animation and activation of another element. So for example you have a button on the right side of the screen, for lets say inventory. When you mouse over or lets say even click on it, the inventory flys out from the right side and into position. So sort of transition options, adds a bit of a pop to things instead of just having a flat is here or is not here setup.