Announcement

Collapse
No announcement yet.

Editor Utility Widgets Feedback

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • started a topic Editor Utility Widgets Feedback

    Editor Utility Widgets Feedback

    Editor Utility Widgets, new in Unreal Engine 4.22, allow you to modify the layout of the editor user interface and set up Blueprints just like UMG widgets. These are Editor-only UIs, and the current implementation enables you to create custom tabs that can be selected from the Windows menu just like existing Editor tabs.

    And we'd like your feedback! How are you using them? What changes would you like to see? We want to hear it all!

    If you haven't experimented with them yet, check out the documentation below or our recent livestream:

    Editor Utility Widgets
    Editor Scripting How-Tos
    Creating Editor Utility Widgets Livestream


  • replied
    Originally posted by SinkingShipEnt View Post

    Editor Utility Widgets Cannot be used on Run Time which is the only way you'd be able to access a normal widget
    Sorry for the late reply, i lost this thread in my notes, I understand, i figured it would be a runtime issue. but i may have to disagree with you a little bit, i was able to call functions created within the editor widget into a regular widget through event dispatchers. you just need a way to save information.

    if i may ask, would you know a way of the resetting a widget after you click "Run"?

    Leave a comment:


  • replied
    Originally posted by Rosium View Post
    Out of the curiosity, Is there a reason why you can not call functions that there were created within the editor utility widget within a regular widget blueprint?
    Editor Utility Widgets Cannot be used on Run Time which is the only way you'd be able to access a normal widget

    Leave a comment:


  • replied
    Out of the curiosity, Is there a reason why you can not call functions that there were created within the editor utility widget within a regular widget blueprint?

    Leave a comment:


  • replied
    Hey all so first of all editor widgets are my best friend atm, i do everything with them. There is one thing i would like added that i find is needed, The ability to create child bps through the widget, I know it can be done by making a factory but as it is already available through right clicking a similar func would be useful

    Leave a comment:


  • replied
    Originally posted by Rosium View Post

    That's great!!
    I have a question though, im working on a project that is still in 4.22, is there anyway getting a reference of the Editor Utility Widget within a regular widgetblueprint? right now, I get warning that it can not access the variable called EditorWidget (a variable ref to my editor utility widget)
    Hi! So, as early as 4.22, we began enforcing a stronger line between editor code and runtime code. It's safe to reference runtime code in editor code, since you have to have it for things like Play In Editor testing. It's not safe to reference editor code in runtime code, as you may be trying to access data that doesn't exist and could crash, etc. You can reference a regular widget blueprint in an editor widget blueprint, but the case you are trying won't be supported.

    Leave a comment:


  • replied
    Originally posted by Shadow.Storm View Post

    In 4.23 Preview, the Editor Utility Subsystem has a function SpawnAndRegisterTab that should be able to help with that, and it just takes the Editor Utility Widget Blueprint as an input.
    That's great!!
    I have a question though, im working on a project that is still in 4.22, is there anyway getting a reference of the Editor Utility Widget within a regular widgetblueprint? right now, I get warning that it can not access the variable called EditorWidget (a variable ref to my editor utility widget)

    Leave a comment:


  • replied
    I was wondering if it's possible in any way with the current Editor Utility mechanics to compile the lights for a level (and get notified when it's done), would be really great for automatizing the process of rebuilding multiple levels when some global setting, actor, material or sublevel changes.

    Leave a comment:


  • replied
    Amazing! Thanks

    Leave a comment:


  • replied
    Originally posted by Oskar Świerad View Post
    Hi! Thanks for the amazing system! I come here with a problem though I can't spawn a tab from C++.

    I put a plugin on the Marketplace and a customer let me know that it's hard to find it in the Content Browser. It turns out that it's a part of Engine Content when installed from Marketplace. So what I'm trying to do is to add a menu button to the level editor (Window -> My tool) that will spawn the Utility Widget.

    The linker complains:


    Is it on purpose that EditorUtilityWidgetBlueprint.h is not a part of BLUTILITY_API? If yes, then at least an exposed function for that purpose would be very useful.

    I based my function on AssetTypeActions_EditorUtilityWidgetBlueprint.cpp. I also followed the invaluable tutorial by IsaraTech, but they just skipped the spawning part (probably due to the same problem)

    Below is the part of my code that causes trouble:

    Code:
    if (!LevelEditorTabManager->CanSpawnTab(RegistrationName))
    {
    IBlutilityModule* BlutilityModule = FModuleManager::GetModulePtr<IBlutilityModule>("Blutility");
    UEditorUtilityWidgetBlueprint* WidgetBlueprint = Cast<UEditorUtilityWidgetBlueprint>(Blueprint);
    WidgetBlueprint->SetRegistrationName(RegistrationName);
    LevelEditorTabManager->RegisterTabSpawner(
    RegistrationName,
    FOnSpawnTab::CreateUObject(WidgetBlueprint, &UEditorUtilityWidgetBlueprint::SpawnEditorUITab)
    ).SetDisplayName(DisplayName).SetGroup(BlutilityModule->GetMenuGroup().ToSharedRef());
    
    BlutilityModule->AddLoadedScriptUI(WidgetBlueprint);
    }
    In 4.23 Preview, the Editor Utility Subsystem has a function SpawnAndRegisterTab that should be able to help with that, and it just takes the Editor Utility Widget Blueprint as an input.

    Leave a comment:


  • replied
    Hi! Thanks for the amazing system! I come here with a problem though I can't spawn a tab from C++.

    I put a plugin on the Marketplace and a customer let me know that it's hard to find it in the Content Browser. It turns out that it's a part of Engine Content when installed from Marketplace. So what I'm trying to do is to add a menu button to the level editor (Window -> My tool) that will spawn the Utility Widget.

    The linker complains:
    error LNK2019: unresolved external symbol "private: static class UClass * __cdecl UEditorUtilityWidgetBlueprint::GetPrivateStaticClass(void)"
    error LNK2019: unresolved external symbol "public: class TSharedRef<class SDockTab,0> __cdecl UEditorUtilityWidgetBlueprint::SpawnEditorUITab(class FSpawnTabArgs const &)"
    Is it on purpose that EditorUtilityWidgetBlueprint.h is not a part of BLUTILITY_API? If yes, then at least an exposed function for that purpose would be very useful.

    I based my function on AssetTypeActions_EditorUtilityWidgetBlueprint.cpp. I also followed the invaluable tutorial by IsaraTech, but they just skipped the spawning part (probably due to the same problem)

    Below is the part of my code that causes trouble:

    Code:
    if (!LevelEditorTabManager->CanSpawnTab(RegistrationName))
    {
        IBlutilityModule* BlutilityModule = FModuleManager::GetModulePtr<IBlutilityModule>("Blutility");
        UEditorUtilityWidgetBlueprint* WidgetBlueprint = Cast<UEditorUtilityWidgetBlueprint>(Blueprint);
        WidgetBlueprint->SetRegistrationName(RegistrationName);
        LevelEditorTabManager->RegisterTabSpawner(
            RegistrationName,
            FOnSpawnTab::CreateUObject(WidgetBlueprint, &UEditorUtilityWidgetBlueprint::SpawnEditorUITab)
        ).SetDisplayName(DisplayName).SetGroup(BlutilityModule->GetMenuGroup().ToSharedRef());
    
        BlutilityModule->AddLoadedScriptUI(WidgetBlueprint);
    }
    Last edited by Oskar Świerad; 07-24-2019, 05:04 PM.

    Leave a comment:


  • replied
    Originally posted by Jerome Parent View Post

    There's no real bug, the ForceHiddenPropertyVisibility flag is doing what it's supposed to, it's just that if you want to only show properties that are marked as InstanceEditable (in BP) or EditAnywhere (native), you can't.

    Based on some quick testing in editor:
    • Every Property created in Blueprint has CPF_Edit regardless of their other flags.
      • When a BP property is marked as InstanceEditable, it loses the CPF_DisableEditOnInstance flag (which seems to be a flag specific to Blueprint properties)
    Personally I think it would be nice to change the ForceHiddenPropertyVisibility flag into an enum where you have:
    • Show everything
      • Current ForceHiddenPropertyVisibility=true
    • Show properties with CPF_Edit
      • Current ForceHiddenPropertyVisibility=false
    • Show only instance editable properties
      • BP: CPF_Edit && !CPF_DisableEditOnInstance
      • Native: Whatever CPF_Edit + EditAnywhere is. Not sure what combination of flags represents an EditAnywhere native property.
    I just don't see the DetailView in its current form being that useful unless you use it only on classes where everything is fully exposed (BP InstanceEditable or native EditAnywhere), because you can't actually change those non-exposed properties if you click on them in the DetailView widget from my experience.

    For example, with these 3 Blueprint properties in a UMG DetailView with ForceHiddenPropertyVisibility=false, I see all 3 properties but only the first one can be changed. The other 2 just don't respond and I have no way of hiding them without moving them into a different category and starting to whitelist the categories instead of showing all properties.
    Click image for larger version

Name:	Properties2.jpg
Views:	1
Size:	6.5 KB
ID:	1645172
    Thanks for the detailed breakdown! We'll look into this on our end.

    Leave a comment:


  • replied
    Originally posted by Shadow.Storm View Post
    Hm - there actually is an advanced flag on the details view to Force Hidden Property Visibility. If that's not on and you're still seeing this behavior, could you report it through the bug tracker? Thanks!
    There's no real bug, the ForceHiddenPropertyVisibility flag is doing what it's supposed to, it's just that if you want to only show properties that are marked as InstanceEditable (in BP) or EditAnywhere (native), you can't.

    Based on some quick testing in editor:
    • Every Property created in Blueprint has CPF_Edit regardless of their other flags.
      • When a BP property is marked as InstanceEditable, it loses the CPF_DisableEditOnInstance flag (which seems to be a flag specific to Blueprint properties)
    Personally I think it would be nice to change the ForceHiddenPropertyVisibility flag into an enum where you have:
    • Show everything
      • Current ForceHiddenPropertyVisibility=true
    • Show properties with CPF_Edit
      • Current ForceHiddenPropertyVisibility=false
    • Show only instance editable properties
      • BP: CPF_Edit && !CPF_DisableEditOnInstance
      • Native: Whatever CPF_Edit + EditAnywhere is. Not sure what combination of flags represents an EditAnywhere native property.
    I just don't see the DetailView in its current form being that useful unless you use it only on classes where everything is fully exposed (BP InstanceEditable or native EditAnywhere), because you can't actually change those non-exposed properties if you click on them in the DetailView widget from my experience.

    For example, with these 3 Blueprint properties in a UMG DetailView with ForceHiddenPropertyVisibility=false, I see all 3 properties but only the first one can be changed. The other 2 just don't respond and I have no way of hiding them without moving them into a different category and starting to whitelist the categories instead of showing all properties.
    Click image for larger version

Name:	Properties2.jpg
Views:	1
Size:	6.5 KB
ID:	1645172

    Leave a comment:


  • replied
    Originally posted by JeromeParent View Post
    Thanks.

    Another question, is it expected that the new DetailsView widget shows all properties even if they are Private (the behavior is the same for native or BP properties)? They cannot be modified in the DetailsView if they are not Public/Instance Editable which makes sense, but the fact they are displayed is pretty weird since they look editable but just don't respond to interaction.

    Is the intended use of that widget to expose one or a few specially-crafted categories of properties and it's up to us to make sure we don't have private properties in there?
    Hm - there actually is an advanced flag on the details view to Force Hidden Property Visibility. If that's not on and you're still seeing this behavior, could you report it through the bug tracker? Thanks!

    Leave a comment:


  • replied
    Thanks.

    Another question, is it expected that the new DetailsView widget shows all properties even if they are Private (the behavior is the same for native or BP properties)? They cannot be modified in the DetailsView if they are not Public/Instance Editable which makes sense, but the fact they are displayed is pretty weird since they look editable but just don't respond to interaction.

    Is the intended use of that widget to expose one or a few specially-crafted categories of properties and it's up to us to make sure we don't have private properties in there?

    Leave a comment:

Working...
X