stride
stride copied to clipboard
[Runtime] Move UI assets to Stride.UI + include StrideUILibrary as root
PR Details
Description
Move UI assets from Stride.Engine to Stride.UI - this is non-breaking as assets are identified by GUID.
Include StrideUILibrary.sduilib as a root asset for the Stride.Engine package.
I've verified nothing is broken by running a few existing samples and creating a new UI page which references the UI library and assets being moved around.
Motivation and Context
Currently when creating a UIPage in code one has to provide all the details for controls, like fonts, sprites, etc. Those assets are available, just not included. This change allows to do the following:
var uiLibrary = Content.Load<UILibrary>("StrideUILibrary");
var button = uiLibrary.InstantiateElement<Button>("Button");
And get a fully displayable button.
I understand that not everyone might want to include the default UI elements in their project, but it's just additional 128KB (less than the default splash screen) and allows to easily create dev UI in code without having to link the font, button sprites, etc. in the asset.
Types of changes
- [ ] Docs change / refactoring / dependency upgrade
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist
- [ ] My change requires a change to the documentation.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [x] I have built and run the editor to try this change out.
Doesn't require documentation change, but: It would be nice to then mention this in https://doc.stride3d.net/latest/en/manual/ui/ui-libraries.html
I need to take a quick look if OK.
In any case, the place it should be is Stride.UI package rather than Stride.Engine.
Did you end up taking a look at this one @xen2 ? @manio143 still needs to come back for that change request though
Hmm, currently the Stride.UI doesn't contain any assets, but I think it should be possible to move the StrideUILibrary into that project while preserving the Guid identifier in order to not cause a breaking change for users.
Sure, I'll change this to a draft then
I just noticed that for example GameProfilingSystem in Stride.Engine takes a runtime dependency on the default sprite font asset. With this PR I'd break it if someone imports Stride.Engine but doesn't import Stride.UI
Is GameProfilingSystem not using DebugText instead of the regular SpriteFont? If using DebugText, it is loading the Debug Font sprite sheet, which is not a "standard" sprite font asset. With this I mean that even if we move the default sprite font asset to other package, if we keep the debug font in Stride.Engine it should work. Shouldn't it?
It uses the FastTextRender rather than DebugText. See here: https://github.com/stride3d/stride/blob/ffd71acc8a8a26a80e5275f833b6e1442e98d01c/sources/engine/Stride.Engine/Profiling/GameProfilingSystem.cs#L354-L358
It uses the FastTextRender rather than DebugText. See here:
https://github.com/stride3d/stride/blob/ffd71acc8a8a26a80e5275f833b6e1442e98d01c/sources/engine/Stride.Engine/Profiling/GameProfilingSystem.cs#L354-L358
Ok, that's what I meant. It is not a SpriteFont but a regular Texture that FastTextRenderer knows how to use. So that texture should stay in Stride.Engine as it is a "private" spritefont-like asset, not something the user can/should use.