Ok so this is a bit hard to explain, but i will give it a go.
First of my experience with UMG up until now there is one word that comes to mind, frustration.
So i know it is experimental so all the crashes i experience i report and move on.
But the work flow i don`t like at all, in my humble opinion the howle process is cumbersome and tedius.
Also i find my self in situations where i set e.g: a grid in a border and set the grid as a variable.
I would then think that getting the slot of that variable and casting it to a UniformGridSlot whould work, but it only works to a cast of border.
Am sure stuff will get better but i like to see some more intuetive work flows.
Like when adding a grid i whould expect to be able to set up the grid before hand e.g: max rows and colums…
And to be able to see it in the editor, apply borders to the grid and so on.
Also i think making stuff simpler can go a long way.
Way do i need to get and cast the slot to even get a hold of stuff like set row and colum?
Its hard to get stuff placed as i want when am only able to put one thing in a border and have only Horizontal and Vertical Box to arange.
I wish we hade more freedom like in/ on the canvas panel.
I will leave it at that by saying it needs a lot of work keep at it.
And you guys at Epic are doing a great job.
The Slot property is the Slot you are in, if the Gird is inside a border, then the Slot property on the grid will be a BorderSlot. If you have something inside the grid, then it’s slot will be a UniformGridSlot.
We don’t currently have a grid with flow layout, which is what you’re looking for. Both the Uniform Grid Panel and the Grid Panel, work off the known number of widgets inside of them.
You can place your grid inside a canvas, and place the canvas inside the border. Then you’ll have all the layout options of the Canvas.
If you place a widget inside a grid, that widget intrinsically has no concept of row/column, it has to have the owning grid give it layout information. Slots are our way of providing that, which we either have to expose with a cast, or alternatively, I my plan is to add an API to parent widgets that do it for you, by providing a function like, T GetSlotForChild(ChildWidget) where T is whatever the slot type is that that parent creates for its children. So it’s still a cast, but the complexities of what type it is are obvious.
Sorry it’s frustrating for you - let me know what else about the workflow you dislike. We’ll probably never ship with an “Uber widget” one that has all the canvas layout options, + border, + hover effect logic built in…etc. Slate tends to err on the side of providing lots of primitive widgets that perform simple tasks so that you can compose them anyway you want. Once I add Named Slot support to UMG, you’ll be able to create your own user widgets that have exposed slots, then you could create a single widget that is Border+Canvas+ whatever else you want, and then re-use it like any other provided widget.
To clarify , it’s because figuring out where the object should be is up to the parent, not the child. If you have a vertical box then that box should tell children where to be, not the other way around. The children can however influence the parent’s decision with the options provided in the slot they occupy. For example, whether they should fill vertically or not.
Am sure some more research will help so thats what am doing.
But i stile stand by my initial statement that i think the work flow is tidius.
Of course the drag and drop part is fine but the BP part that follows i don`t like.
It forces me to implement a Blueprint e.g: player controller as a Blueprint when i prefered that to be just in code.
Maybe not a big deal to some, but i feel it prevents my regular work flow of things.
Forcing me to make decisions I other wise whould not.
And a follow up qustion?
Is the default HUD class now useless?
We’ll be making the C++ workflow easier in the future. We decided to start by making UMG something both programmers and non-programmers alike would find accessible. Hopefully you’ll be able to simply define the look and feel in the BP designer, and then define the code-behind somewhere else at some stage in the future. Right now, you can avoid writing the logic in a BP, by either extending UUserWidget in C++ and reparenting the BP, then call any function you defined in C++ from the BP, instead of doing the logic in the BP. Alternatively you can place it all in a C++ Model object that you pass to the UI.
4.5, several of the previously only overridable UUserWidget functions are now also overridable in C++.
Nope, AHUD is not useless. It still has the best support for primitive drawing capability. One idea for AHUD’s future is that it becomes another place to host widgets. So the viewport remains the full screen widget location, but the AHUD becomes the way you can add widgets to a particular persons screen in splitscreen situations.
Also one qustion i derived a class from UUserWidget:: but how can i use that class as a Widget Blueprint?
#pragma once
#include "Blueprint/UserWidget.h"
#include "InventoryWidget.generated.h"
/**
*
*/
UCLASS()
class MYGAME_API UInventoryWidget : public UUserWidget
{
GENERATED_UCLASS_BODY()
};
It seems I only can make it a regular Blueprint and not a Widget Blueprint.
Will this work in 4.5?
When you say re parenting you mean set the extended User Widget class as the parent for the Created Widget?
I whould then think that it whould lose all the stuff am adding in the Editor?
On the toolbar on the graph view, hit the Blueprint Params button, clicking it gives you the options needed to reparent the blueprint from a UUserWidget to some derived version, you wont lose all the things in the editor, it just swaps out the base class in the Blueprint.
