Hey, https://docs.unity3d.com/Manual/UIToolkits.html says: UIElements Runtime Game UI: TBD So, whats the plan? Will there be an alpha? Soon? Thanks Philipp
Who knows, but it seems like most of the main features of the editor version are working right now. I am using it for an editor script without many issues.
Can't come soon enough to be honest. A more flexible layout for different screen widths would greatly improve development times.
Nope, it just means more info will be released during that talk, along with concrete usage examples and a more detailed roadmap. Though, we might release some details sooner. EDIT: Like right now, below.
We just posted our roadmap for UI. The main points: Preview package will be released with 2019.3 We will iterate on it during the 2020 cycle A Verified package will be released in 2020.3 Very open to feedback at this stage so feel free to let us know what you think. Cheers
Naming is hard. "Unity UI" or "uGUI" is a completely different UI framework for Unity than UIElements. They have nothing in common. Now, while the UIElements runtime package does work with 2019.3.0b6, we are still actively working on it and will share it publicly once Unity 2019.3 fully releases (out of beta) - around mid- to late-November.
So just to clarify, we can currently use the UI Builder package (and even preview runtime theme in the builder) in 2019.3 beta, but It won't be until 2019.3 goes out of beta that the UI Elements Runtime package will be released, allowing us to actually see it in the game view like we did in the Unity talk? This is done using a PanelRenderer component I read? And we have no way of accessing that right now. Really looking forward to playing with this!
Bad news: it's been delayed. Good news: the full Unite demo project is now available for feedback purposes. https://forum.unity.com/threads/uielements-roadmap-update.784388/
NICE! The example https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo contains everything in package layout. So you could easily build an npm package or just import it as package from disk... Just did, and now started prototyping with UI Elements and Runtime
Are there any updates to the Timeline? Im experimenting at the Moment with the 0.0.3 Version from the Demo in Github, but wanted to use a newer version, due to some bugs (f.e. in Build the uss files are sometimes not found)
As stated in the last update, we're still aiming at releasing the new package with the release of Unity 2020.1
I was waiting for the availability of UIElements runtime to start learning UI Elements. I'm hoping to get a fair amount of UI reuse between the editor and runtime. One thing I'm finding puzzling is why some stuff is in the Editor namespace. See for example: https://docs.unity3d.com/Manual/UIE-ElementRef.html but also a bunch of stuff related to bindings etc. Obviously the more stuff that's in the editor namespace, the less opportunity there is to share effort between editor and runtime. But more than that - it seems some workflows will have to be rethought. Even if we don't get code reuse, I'm trying to preserve brain space as UI is fairly low down on the list of things that I get excited about and I would prefer to be spending my limited time and energy of the more groovy side of things.
Some controls, like ObjectField, will never make sense at runtime. Others, like PopupField, might make sense at runtime and we are looking at moving these to the Engine namespace (to runtime). They are Editor-only today because they rely on some Editor-only feature (system right-click menus in the case of the PopupField). Can you expand on this? What part of the workflow are you seeing as problematic? Is this a reference to how there are Editor-only controls?
That makes sense. (I have to keep mentally translating "popup" to "drop-down" - is it just me or is that a strange choice of name for a fairly common widget? When I see "pop-up I think of something more like a persistent tooltip or a small modal window.) How about the stuff under "Complex widgets"? It's not clear what the binding workflow is as a lot of the editor examples use controls that are in the editor namespace. Really - it's this same point - I'm not clear how much stuff from editor tutorials will translate to runtime - especially in terms of binding. (which for me is one of the big appeals of UIElements as it promises to reduce the amount of repetition and boiler-plate) Mainly yes. I'm just looking for an understanding of how to get runtime controls up and running quickly. Currently I'm looking at "runtime inspector" type applications for fast prototyping.
This was just to be more consistent with IMGUI. So...because legacy. Where do you see "Complex widgets"? The plan is that all the bindings workflows will eventually work at runtime. We might have to change some things but the idea of giving elements a binding-path to a field and then having the UI and data be kept in sync will still be there. If you're talking about today, right now, then none of the tutorials around UIElements and bindings will apply for runtime. That said, apart from bindings and some fields, most of UIElements will work the exactly the same when used at runtime so most tutorials will still be applicable. Cool. The plan on our side is to eventually have zero controls that only work in the Editor when they could, in practice, work at runtime. This includes all the choice fields (like PopupField). The only exceptions are maybe something like the ObjectField which doesn't map well to runtime. This will be a migration, not a duplication (at least, in the end) so there shouldn't be too much code and API duplication. If you want to start some of those ports for your own use, that's also an option and implanting a simple bindings system on top of the `binding-path` attribute is very doable. You have all the necessary parts in the API.
Hi, i tried building the https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo to android. The buttons are working fine, but the list view is not scrollable if we drag fingers across the list elements. The scrollbar works fine. Is there something i missed with the android build?
Yes; that its an early preview that doesnt support android properly. There are some workarounds available, but sooner or later you'll run into issues that cant be fixed for the moment. Best wait for 2020.1 alpha to have the runtime package.
Hello ! I see a lot of changes on UIElements at runtime in the Unity 2020.1.0b2 release notes. Does it means it is now included ?
Also curious about runtime. Been looking around but still can't find anything that resembles panelrenderer which has been shown before.
Please read the top of this thread, starting with: https://forum.unity.com/threads/uielements-runtime-plan.727559/#post-5222915 But to repeat, runtime support will come as part of the transition of UI Toolkit (formally UIElements) to a package. We are aiming for 2020.1 timeframe but might come a bit after that. The full release of production runtime support is currently slated for 2020.2.
Since I was interested to work at the UI Runtime system and I wasted a big portion of my day trying to understand how, I assembled a little wiki to do that. I hope it will save time to other fellow developers. https://medium.com/@raynor85/new-unity-uielements-runtime-system-how-to-use-it-now-f560c4cb22d2
I might be missing something, but I'm on 2020.1.2f1 and I don't have a PanelRenderer available even after adding the UI Builder package.
Because you have to also install the UI Toolkit package manually by adding it to your manifest.json - it's described in the announcement post. Also, the PanelRenderer is now UIDocument. https://forum.unity.com/threads/ui-toolkit-1-0-preview-available.927822/