Yeah there’s much better support for just dragging objects around after initial placement, though it’s still not perfect. Need more stable maths to keep things sized correctly if they have non-default anchoring.
I downloaded the 4.3 preview release from git a couple of days ago just to play around with this. Is there something like a z-index to help with layer order when items overlap?
I like where it’s heading though. Good job! Despite the lack of any real info, I took a basic 3rd person BP template and managed to throw together a pseudo menu of sorts with sliders to change bloom and contrast… that post-process node… wow, that’s a lot of connectors on a single node, but irrelevant to this topic. 
For anyone interested in trying it out, it looks like 4.3 will no longer be using the widget blueprint as an actor that you drag out into the level. To get access to it, after making your widget BP, either in the level BP or PlayerController BP (I used PlayerController EventBeginPlay), create a widget, cast to your widget BP, then call show on it to see it, and hide on it to… well, hide it.
PlayerController:
Level:
Widget:
Edited for slight clarification and to add last paragraph/photos
Yeah there’s a Z-Index for any widget placed on a Canvas, should be near the very bottom of the details. The way UMG and underlying slate works, is depending on which container you’re in you receive a different Slot object that has the properties relevant to that container.
Fastest response ever!
I didn’t use a canvas, as it didn’t have a color setting, so I just used an image and set the color to black as a background. Works fine for the most part, but layering was being a pain. I’ll take a closer look at the canvas, thanks.
Update: After looking over it a bit, I see the hierarchy panel but rearranging from there seems to be copy paste delete. Not a big deal, but I also looked at the canvas panels a bit closer and by putting different elements inside different panels, the panels can then be rearranged much easier than individual components.
Thanks! I’ll probably be diving in soon anyway. So I’ll find out a lot more later.
Currently trying it in 4.3 Preview - struggling to do anything other than display buttons etc. I like how it looks so far though - minus being very crash prone (to be expected)
Any chance you could create a simple tutorial on creating a slider to change bloom or similar.
So in the 4.3 release notes I saw this:
- New: All existing UMG assets should be abandoned, no upgrade path is provided for them.
What does that mean exactly?
Normally we write a lot of code to preserve the users work to ensure it’s not lost as the underlying structure of the system is changed. In the early days we’re avoiding this to make it easy for us to change things as necessary. You should not attempt to load your existing UMG assets from earlier version in 4.3, as they will likely fail in spectacular ways 
Good to know this in advance 
Is this likely to also be the case when the next major update arrives?
This could be the case for probably 4.4 and 4.5, however I’m now making some effort to preserve existing work going forward.
UMG in 4.3 feels a lot more usable, its actully my first interaction with Slate and it feels like Android UI system which is layout based containing widgets in widgets.
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.
Nice
Mouse interference - should be fixed in 4.4, you can now choose when adding a widget to the viewport if it’s modal or not, aka menu screen or HUD.
Percentage Position and Sizing - 0…1 positioning will work in 4.4; when widgets are added to the viewport, we now add them to the same type of canvas used in UMG, that lets you set anchors and such. So now you can adjust the anchor position to get the same desired effect. As for size… scaling size is tricky. The plan is to expose…somewhere a DPI curve that lets you configure how to scale the whole UI at different resolutions. That will give you a finer grain control, though we’ll probably pick a reasonable set of defaults. Also since the new viewport canvas is the anchor canvas, we could just make it easy to set the size scaling files of the canvas slot by letting you change the anchor points directly, then you could set anchor health bar at 0.1 and then also anchor it at 0.4, and now the slot would increase in size to keep it anchored there.
Can you post some pictures of what you mean about the chat/tab stuff?
Can you explain more about the issue with slots, and them being clunky? Currently slots exist, but they’re hidden, the layout properties are exposed through the details panel on the widgets they affect so that you can have a sort of one stop shop for all things affecting some widget.
Animation and transitions are something we’re very interested in adding/improving. We’ve been batting around a lot of ideas to give you access to those kinds of events on every widget in a safe way, so that you can’t impede slate, but at the same time get the info you need to have awesome transition animations.
Cheers,
Nick
How do I go about responding to mouse click events?
I’ve added a ‘FrontEndTest’ widget and added the necessary blueprint scripting to create it and call ‘Show’ on it.
I’ve also added 2 buttons, and I set their ‘OnClickedEvent’ to new events ‘GetOnClickedEvent_0’ and ‘GetOnClickedEvent_1’.
I’d hoped I could also have events corresponding to these in my level blueprint so I could respond purely through BP, but no such luck.
How do I go about responding to these events in either C++ or blueprint? Or is it not enabled yet?
All of the handling of individual widget events is currently designed to be handled in the widget blueprint itself. If you need to expose something outside of the widget the idea is that your widget would expose the high level concepts via new events, OnPlay, OnSettings, OnPause…etc.
@NickDarnell Is there a reason why i have to doubleclick on a button to set ‘is Pressed’ to true? (In other words… when i single click on the button it prints ‘false’ , when i double click on the button it prints ‘true’. Some times i have to click 5 times in a row to get a is pressed = true value. I noticed that when i press twice per second it doesn’t respond at all… Only if i click really fast. Very strange.
note; i created a top down camera and enabled the mouse cursor and stuff as i’m planning on making a ‘city builder’ game.
Also i would like to see the graphs you build for that blue popup widget. Any chance? There is so little info about umg (of course because it’s in development) but as many others you know… as a little kid that knows that ice cream car is just around the corner …
The TestWidget defaults:
&stc=1&d=1406840792
The TestWidget graph:
&stc=1&d=1406840841
Create the TestWidget graph:
&stc=1&d=1406840851
The tool is really nice so far, especially for something that’s not ready for prime-time.
I updated to the 4.4 preview build, excited to try out some of the improvements mentioned above. Sadly, I ran into a problem: No visible UI. It appears there is no longer a show function for a widget. I’ve tried using set visibility instead, but no luck.
The simple setup in my level blueprint looks like:
Very similar to how it used to work.
Should this work? If not, how should it work?
Any help would be appreciated.
I think you need to check out the source to grasp what has changed. (or wait of course 
)
@Jeremy It’s no longer Show/Hide, it’s now Add to Viewport, Remove from Viewport. Better names for what is actually occurring, i wanted to distinguish it from visibility changes
@Nique I’m working on a living set of docs for the forums, basically a quick start guide. It’s going to be very basic, but it should get people started. Will link to the thread after I finish it.
Sorry for the late reply. I was sidetracked on a different project and wasn’t keeping up with this thread. The announcement of 4.4 preview today reminded me to come check out this thread.
The sliders are really simple. The hardest part is sorting through the post processing node to find the values you want. What I did:
In player’s controller, after setting up the widget blueprint, I call create widget with widget type set to the widget blueprint I made.
I took the return value from that, cast it to my widget blueprint and promoted to variable, called BP_Widget.
In the level blueprint, begin play, get controller->cast->get BP_Widget->promote to local variable.
Still in begin play, get post process volume->get settings->break post process settings->promote blendables to variable.
Trigger the settings change however you wish. To make the change:
post process volume->set settings->(pull backwards (left) off of settings)make post process settings.
BP_Widget_Local->get slider->get value->tweak if needed->plug into make post process settings.
Plug the blendables variable into the blendables pin on make post process settings. Done.
Notes: a lot of the post process settings will have a bool that also has to be set to override. All the bools are towards the top of the node, the values towards the bottom. Where I have tweak if needed, I had two sliders set up, one for contrast, one for bloom. The one for contrast seemed way too extreme, so I have it divided by 5. The bloom setting seemed to work better by multiplying. I set mine to * 3.
Hope that helps.