- removed dummy UClasses (no longer needed)
- removed file header comments (not used)
- removed duplicated function documentation in cpp files
- documentation cleanup, punctuation, spelling etc.
- pragma once include guards (now work on all platforms)
- relative public includes (are auto-discovered by UBT)
- fixed too many/too few line breaks
- deleted empty files
- missing override
- NULL to nullptr
[CL 2305058 by Max Preussner in Main branch]
Device Services Refactoring to create the concept of a physical device.
Game launcher and device viewer UI changes to show these new concepts.
#codereview Max.Preussner, Matt.Kuhlenschmidt
[CL 2290918 by Chris Gagnon in Main branch]
Cocoa isn't an event-polling API as UE4 expects, so previously we were subverting the NSApplication's event handling to pretend that it was. When the engine wasn't running the event loop fast enough, such as when loading where it isn't processed at all, this resulted in unresponsive windows and Spinning-Beachball-Of-Death. That isn't very satisfactory & to some users appears as if the application has crashed. To address these deficiencies without further attempts to subvert Cocoa, the game is now punted onto a separate thread where it can run its own tight-loop, leaving the main thread to handle the Cocoa event run-loop. Events are captured by delegate objects, as Cocoa requires, but dispatched and handled on the game thread which makes Cocoa appear more like other platform APIs to the higher-level UE4 code.
This can all be disabled using the MAC_SEPARATE_GAME_THREAD define in CocoaThread.cpp.
#codereview michael.trepka
[CL 2262543 by Mark Satterthwaite 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]
I also added code to retain backwards compatibility. Existing settings from EditorUserSettings.ini will be migrated to EditorLayout.ini
#CodeReview: nick.atamas, matt.kuhlenschmidt
[CL 2074798 by Max Preussner in Main branch]
Other Updates:
- The WidgetReflector is now in its own module as well. It will be converted to a plug-in later.
- The Public API of both Slate and SlateCore has largely been reorganized for better discoverabilty. More cleanup work is needed.
- Added a lot of missing API documentation and fixed existing ones. More and better documentation is needed.
- Removed dead code, fixed a couple things I stubled upon, and conformed to coding guidelines (NULL vs nullptr, line breaks, etc.)
Upgrade Notes:
- The Slate Remote Server is currently disabled - will be re-enabled shortly!
- If your module previously had a module dependency to 'Slate', it now also needs a PrivateModuleDependency to 'SlateCore' in its Build.cs file.
- If your module exposes in any of its Public header files types that are now declared in SlateCore, it needs a PublicModuleDependency to 'SlateCore'
- The ToolTip property type on SWidget has changed from SToolTip to IToolTip; change local variables to TSharedPtr<IToolTip> instead of TSharedPtr<SToolTip> where needed
- IToolTip is not a widget. If you need access to the actual widget that represents the tool tip, use IToolTip::AsWidget(); If you need access to the tool tip's content, use IToolTip::GetContentWidget()
Troubleshooting:
- After syncing to this changelist you may have to clean your /Engine/Intermediate/Build/ directory and rebuild your entire project
- If in your project you are getting linker errors for unresolved types that are now declared in SlateCore, you may be missing a dependency to 'SlateCore'
- If in the Engine code you are getting linker errors for unresolved types that are now declared in SlateCore, you may need to rebuild the entire Engine
[CL 2057118 by Max Preussner in Main branch]
#ufe
* added some modules to the UFE dependencies so they are properly built even tho there is no direct dependency
[CL 2050335 by Peter Sauerbrei in Main branch]
