Newly installed versions of the engine will now attempt to copy the project-agnostic config settings from a previous engine installation. This happens by way of a versioned manifest that copies old versions when the manifest does not exist, or is a different version. This code path is benign for non-installed versions of the engine (or FPaths::ShouldSaveToUserDir() is false).
EditorGameAgnosticSettings and EditorUserSettings ini paths have been renamed to EditorSettings and EditorPerProjectUserSettings respectively to better convey their purpose. In general, most settings should be saved in EditorSettings (project-agnostic) so that they apply regardless of which project is open. We have some way to go migrating existing settings for this to be the case, however.
Some previously per-project configuration files are now project-agnostic (such as Editor.ini, EditorKeyBindings.ini, and EditorLayout.ini)
GEditor->Access...Settings and GEditor->Get...Settings have been removed in favor of direct access of the CDO through GetMutableDefault<> and GetDefault<> respectively. Global config ini filenames that are not set up are now neither loaded nor saved on build machines, to handle the problem of indeterminate state more generically.
This addresses UETOOL-270 (Most editor preferences should be project-agnostic)
[CL 2517558 by Andrew Rodham in Main branch]
- Combined 2D Rotate / Translate widget
- 2D Layer Snap planes
- Some UI stuff to go with it
#codereview michael.noland
[CL 2500349 by Dinesh Kumar in Main branch]
You could previously only have them enabled or hidden, you can now add them as disabled.
You can also now bind the menu item state to a delegate to let it update after the tab spawner has been registered.
#codereview Nick.Atamas
[CL 2341064 by Jamie Dale in Main branch]
- made public headers compilable individually
- moved interfaces to public root
- removed module singleton getter
- code and documentation cleanup
#UpgradeNotes:
- instead of ISettingsEditorModule::GetRef() use FModuleManager::GetModuleChecked<ISettingsModule>("SettingsModule")
- instead of including SettingsEditor.h include the interface headers you actually use
[CL 2340730 by Max Preussner in Main branch]
- made public headers compilable individually
- easier access to settings section delegates
- removed module singleton accessor
- moved non-trivial definitions into cpp files
- code & documentation cleanup
#UpgradeNotes:
- instead of ISettingsModule::Get() use FModuleManager::GetModulePtr<ISettingsModule>("Settings")
- instead of using FSettingsSectionDelegates assign delegates directly through the new ISettingsSection methods
[CL 2340711 by Max Preussner in Main branch]
* Moved Slate.h into SlateBasics.h and began shifting less commonly used headers into SlateExtras.h.
* Slate.h now simply includes SlateBasics.h and SlateExtras.h.
* Slate.h includes a deprecated warning now to indicate that SlateBasics.h + specific includes should be used instead.
* Moved dozens of inlined functions using Slate widgets into .cpp files to avoid header dependencies.
* All code samples now include SlateBasics.h and SlateExtras.h so future shifts will not break most those projects, but not trigger the deprecation warning of including Slate.h.
#BUN
[CL 2329610 by Wes Hunt in Main branch]
Please note that file comments had no purpose in nearly all cases and just added visual clutter. The two files that had meaningful file comments had their comments moved into the corresponding classes. There are still hundreds of file comments left in other files that will be removed over time.
Also cleaned up some random stuff along the way:
- relative paths to public headers within the same module are no longer necessary (automatically discovered by UBT now)
- header guards are deprecated, use #pragma once instead (all compilers support it now)
- space between multiple template brackets is no longer required (all compilers support >> now)
- NULL to nullptr, OVERRIDE to override
- spelling errors, whitespace, line breaks
[CL 2104067 by Max Preussner in Main branch]
TTP# 332489 - TOOLS FEATURE: Editor: Allow user to designate which platforms a project is designed for; warn user when deploying to platforms that will result in a bad time
There is now a "Target Platforms" tab in the project settings which allows you to choose which platforms your project will target. This information is stored inside the .uproject file.
If you try and launch, cook, or package for a project that isn't on the supported list, then you'll see a suppressible warning notifying you that the project may not run as expected. This is also conveyed to you via a warning icon next to platforms which aren't set as a target.
Additionally the target platform icons are shown in the tooltip on the "Open Project" dialog, as well as in the tab area of the level editor.
ReviewedBy Thomas.Sarkanen, Max.Preussner
[CL 2088161 by Jamie Dale in Main branch]
#ttp 335130 - EDITOR: Keyboard Shortcuts: Toast falsely warns of failed import if prompted for save
#branch UE4
#proj Editor.EditorSettingsViewer, Editor.InputBindingsEditor, Editor.UnrealEd, Developer.SettingsEditor
#add Added FEditorSettingsViewerModule::HandleInputBindingsSave as a SaveDelegate for the keyboard bindings section, whose purpose is just to remove user gestures so nothing is flushed to config at editor shutdown, and hence does not supersede the freshly copied imported config.
#change Changed the message in FEditorSettingsViewerModule::ShowRestartWarning to inform the user that changes will not take place until after restart.
#change Fixed input binding editor behavior so that valid gestures are committed immediately instead of requiring a change of focus.
#reviewedby Max.Preussner
[CL 2079970 by Richard TalbotWatkin in Main branch]
Settings specific to Anim, Blueprint and Material Editor should probably be broken out into their own settings classes in the respective modules at some point. It feels a little strange that the GraphEditor needs to be aware of specific pin and node title types. At this time I did not want to refactor the existing graph editors though, and since many of the properties are currently being shared, pulling these settings out of UEditorUserSettings is at least a good first step. In the future I would like to see settings sections for specific graph based editors instead of having a generic 'Graph Editor' section that is shared by some or all editors.
I exposed various color settings in the UI as many users seem to be quite excited about customizing their Editor. If you think that some settings should be added or removed, please feel free to make any desired changes or let me know. Thanks!
#CodeReview: nick.whiting
[CL 2079703 by Max Preussner in Main branch]
