Why is CommonUI lacking of features, legacy UI and Input were able to handle?

Hi there…

This, in some places, is kind of a rant…
I´m working with CommonUI for multiple Weeks now… and since two Weeks… my project completely got stuck… I can´t go on with it, cause CommonUI breaks the development pacing… so… pls forgive some harsher words…

The following is a List of Features and/or Functionalities, CommonUI does not, worse or overcomplicated as hell… And in many cases, the legacy UI and Input system… were able to do that stuff better… and easier… and better documented… (if you can speak of documentation in the case of CommonUI…).

In the following, the legacy UI and Input system will be called “Legacies”… while CommonUI and Enhanced Input will be named “Futures”.

So… let’s begin… and perhaps some of you can answer questions of this list…

1.) The Input forwarding to Widget Events.
While with the Legacies, you can have Axis and Action Events for Inputs of your ProjectPrefs in the Widget Graphs itself. This is not possible in the Futures… I don´t know why… but Enhanced Inputs are not forwarded to Widget Events… no matter what Input Mode is set.
Meaning: No additional Events to handle special Keybindings…
Which leads to…

2.) Key DataTable and… no Events?
We can define an Input DataTable for CommonUI, to bind keys for keyboard and Gamepad to a row. We can set the keys, overrides for Button-swaps and can activate a hold-key system.
Now… I think CommonUI is not thought to the finish… Since… Confirm, Cancel, Directions… work well…
We also can define more keys… f.e. for Next and Previous… But…
How are we able to use that?
Buttons can have a single Input Trigger Action assigned. Which is ok for simple Buttons.
But, what about Itemslots, where facebutton-left/-top/-bottom… are used to drop, move, use items?
How are we able to do that stuff, without an “OnInput_XXX” Event?
Even more… perhaps OnKeyDown could be an answer… but we are no allowed to compare keys to the DataTable…


Cause the Struct variable for the keys… are not exposed…
And IF there is a way to do that… why THE ■■■■ is that not documented anywhere? And if it is documented on some place in the wide world of the endless internet… WHY, is it not public and better communicated to the users?
AND… if that would do A trick… It will only wok when the Button is focused… since without a focus, OnkeyDown does nothing!
Which leads into…

3.) How the ■■■■ do Inputs without Focus?
Weeks of searching… no result found… No Video… no Document… No paper… Not anything…
If we define keys for Next, Previous, NextTab, PreviousTab…etc
They are not Button bindable keys… Cause those Buttons need to act for a whole UI system… no matter what Button is focused… which again is Part of Problem 2… But a whole independent topic. We definitely NEED Input Events to workaround this… But tying those to functions would be great, too.
So… perhaps one knows an answer on how to do that… I currently give up on that task…

4.) (not) Fun with Focus
We have the Events OnActivated, OnFocusLost…etc
Ok…
We can override the GetDesiredFocustarget… ok… which is again just linked into a SetKeyboardFocus or SetFocus or both together… no matter… since that system is not working as it should…
I push my inventory to the viewport stack… OnActivated set the Focus (both) to the first Slot… and… Nothing… no focus for the Slot… or any other focusable object in the inventory…
There has to be a huge-improved function to deal with focuses in Common UIs better…
It happens to me, too… That I hovered a Button with the mouse and then moved the focus with the Gamepad… and now got 2 Buttons selected…
OR…
I have the first button of my Main menu focused per Construct as default. Works…
Now I select the third button… no matter if with mouse, gamepad or keyboard keys… If I now confirm the button to trigger it… CommonUI still wants to trigger the first button…
To come over that problems… I wrote my own Subsystem to store the last selected and new/currently selected Widget, to only trigger the current one… and remove the hover effect and focus from the LastSelected,…It´s just not working out of the box… and I literally followed the official video… 5 times… until I wrote my own subsystem to move on…

5.) Disable default bindings?
Now… I created an Input DataTable, the Key Data to have icons…etc…
I managed (with headaches, crying and tearing out my hair) to set focus to a button in my Inventory. D-Pad Input works. I can select different slots in all 4 directions.
The problem now is, while having the inventory opened, I want the player to be able to walk on the map. But… Unreal per default sets the Thumb sticks as UI input, too.
How to disable that? I want UI control on the D-Pad only…
Again, no Option, doc, paper, video found to that topic… and it’s annoying to have the Slot-Selection moved, while the Character moves… And yes… it’s essential to have both working parallel.

6.) The Viewport Stack is… ■■■■… compared to a canvas
When I add my Inventory to a canvas, I can set a position, anchor, alignment, offset and pivot, to perfectly set the Inventory-Widgets position inside the Viewport.
For the Viewport Stack, I found “SetWidgetSlotPosition”… And this is the only Function for a stack widget, to set a position… And, it is not working. My Inventory stay at the top right corner all the time, no matter what values I put in.
Curious here: If I put the same values into as Canvas Slot, it works perfectly for the Widget at that Slot…
Again, we have 0.0000000 Documentation of the topic of setting the positioning of a pushed Widget on the Stack… HOW, is that supposed to work?
This makes me realize that CommonUI seems to be made ONLY for Screen filling UIs… and not smaller Windows covering only parts of the screen…

Conclusion:
I more and more get the feeling… that CommonUI is made for Lyra… not for the (guess it… guess it…!) Common usage…
I don´t know how all of this should work… But it IS NOT documented… Yes… you can send links to the unreal docs covering… literally nothing of my questions…
We have an official unreal video of a person, not remembering how to do stuff, until minutes later, just to jump back and forth… more unprofessional than documentary worthy…

I think CommonUI is not ready to be public… or being out of experimental at all…

I hope someone can help out here… cause after searching for answers and looking through forums, discord server, Youtube comments…etc…etc… I’m not the only one having that problems…
So please Epic… DO SOMETHING… pls…

I agree with you after experimenting with it. It seems like a pretty poor system. It’s all well and good with the supposed time savings, but you couldn’t really use it in a game with the current failures. The double click a deactivating widget button alone makes the whole system unusable.

The Content Example project, with the Common UI map, for example, shows the failures. If you press A on your xbox controller twice during one of the close widget animations, the widget focus completely breaks because there’s no way to stop a double press / click. You can’t stop it with bools or do once or delays or anything.

It’s nothing to do with the execution node as it’s the click even itself that is the problem. You can cheese it with some weird work arounds but it’s meant to be a simpler system, not worse.

The only reliable solution is to set the transition time on activatable widgets to 0, which means no animations.

Plus with CommonUI there must be at least 6-7 different places you setup inputs.

All in all, it feels like you’d lose more time with common UI than just taking the longer road with the current system and practices.

1 Like

IMO The proper name for CommonUI should be ConsoleUI, it seems like they wanted to make a UI with console in mind then they made a ConsoleUI. Using CommonUI with PC is not pleasant, issues with cursors, mouse clicks and even Activitable widgets eat all input by default no matter what settings it have, I have a widget that consumes any mouse click no matter where you click on the screen even though my InputMode is Game

it’s letterly a pain to learn, even Epic’s tutorials has some issues with it

1 Like

Common UI is completely unusable in real life, it works on bare-bones tutorial, but as soon as you want to customize a bit, you found a ton of obscure behaviors, that are not documented anywhere. It has a very complicated setup, and lacks a ton of features of the legacy version. I’m now going to refactor and get rid of it in my project, you’re better off building your own system based on a well documented fundamentals.