Search Unity

Renaming UIElements to UI Toolkit

Discussion in 'UI Toolkit' started by benoitd_unity, Mar 26, 2020.

  1. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    331
    As mentioned in the Unity 2020.1 beta blog post, we’re renaming UIElements to UI Toolkit. The new name better describes the set of features and functionality that the UI Toolkit contains, including the C# VisualElement API, the UXML and USS assets, UI and Event Debuggers, and the UI Builder. The name "UIElements" has become inadequate at referencing all these tools and features and would often conflict with the generic "UI elements" term.

    You will see a gradual transition in the naming for our Editor menu and window names, forum, documentation, and marketing material, as we get closer to releasing the UI Toolkit.

    As for the C# API namespaces themselves, currently UnityEnigne.UIElements and UnityEditor.UIElements, they will not be changed in the near future to ensure a smooth transition as we move to UI Toolkit being a package. More on the move to a package here:
    https://forum.unity.com/threads/uielements-roadmap-update.784388/
     
    benoitd_unity, Mar 26, 2020
    #1
    PixelLifetime and kvfreedom like this.

  2. oltranzista

    oltranzista

    Joined:
    Jul 21, 2015
    Posts:
    5
    Renaming it to avoid conflicts with the generic "UI elements" term is great news as I had trouble doing google searches about this unique feature and got results from old tech from 4 or 5 years ago.

    While we're talking about renaming things, is there any chance of renaming the UnityEngine.UIElements.VisualElement base class to just UnityEngine.UIElements.Element? The two word identifier makes the uxml markup a bit more noisy than it needs to be. Plus if it's a base class of all the elements it might make sense to drop the "visual" adjective and just go with the noun "element". It's probably way too late to consider a rename and it would probably cause too much churn but I just thought I'd mention it just in case.
     
    oltranzista, Apr 6, 2020
    #2
    Lahcene, PixelLifetime and Catsoft-Studios like this.

  3. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    331
    Yes you're right, it's a bit verbose to my taste as well. Although at this stage we're not ready to make this level of breaking change, we're considering renaming the Namespace at some point and this could potentially be included.

    Thanks for the suggestion.
     
    benoitd_unity, Apr 6, 2020
    #3
    Lahcene and PixelLifetime like this.

  4. E_Nickelodeon

    E_Nickelodeon

    Joined:
    Dec 19, 2017
    Posts:
    3
    This is a huge help! UI Elements is such a generic term it's made finding new info a lot harder to parse in search results.
     
    E_Nickelodeon, Apr 8, 2020
    #4
    Lahcene and benoitd_unity like this.

  5. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    1,090
    @benoitd_unity When is the rest of Unity going to get the message about the renaming? Yesterday's 2020.2a10 release notes still refer to the system as UIElements.

    Or... is this going to simply be a constant source of confusion due to the fact that the actual code will remain "UI Elements" whereas the overarching technology will get the bundled name "UI Toolkit"?
     
    SonicBloomEric, May 7, 2020
    #5
    JoNax97 likes this.

  6. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    331
    Yes thanks for pointing them out. Those are probably old tasks that were not renamed before landing in the codebase. Expect a, hopefully, short transition :)
     
    benoitd_unity, May 8, 2020
    #6

  7. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    So is the rationale behind waiting with that change that changing the namespace for the package will make it easier to switch to the package? Or is it to avoid having too much "change noise" right now?

    Because in general, I think changing namespaces is always less painful the earlier it happens, and if it's just changing the name of a namespace (vs. changing the structure of several namespaces), is trivial to port. Unity's auto-updater should be able to do this easily, and it could also be done trivially with a global search and replace.

    For code that relies on these namespaces and that has to support different versions, conditional compilation will be necessary. But there, again, the earlier that change happens, the less painful it will be for most people.
     
    jashan, Jun 3, 2020
    #7
    Lahcene, ErnestSurys, Lurking-Ninja and 2 others like this.

  8. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    331
    It was mostly to limit the number of changes to handle at the same time.

    I also agree with you that doing this kind of change early is easier to do but on the other hand, we felt like leaving the namespace as it is for now was not a big deal, unlike public facing references such as editor menu items, documentation and marketing material.
     
    benoitd_unity, Jun 6, 2020
    #8
    jashan likes this.

  9. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    1,090
    @benoitd_unity The consensus from devs I've spoken to in various communities is that this is simply something that should happen and there's surprise/confusion as to why the team is simply sticking with the UIElements namespace.

    If you're concerned about an upgrade path, isn't that exactly what the API Updater is for? Is there something that stops the API Updater from working on packages?

    Regardless, the shift from built-in to package seems like an excellent time to make such a shift, especially while your 1.0 is still in preview.
     
    SonicBloomEric, Aug 7, 2020
    #9

  10. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Our package strategy is a little different in that we still have most of the core and Editor APIs in Unity. The package is a _mirror_ of the modules Unity and it's an optional install. The idea is that you can use UI Toolkit without the package installed, but can optionally install it to get the latest version (and for now, to get the additional runtime support). This was done to avoid creating yet another version of the API, one available in Unity and another available via the package. We kind of have enough UI APIs.

    So given we wanted to keep the same API both in Unity core and the package, we would have had to change the namespace in all parts of Unity and all packages that have already started using UI Toolkit. Even with the API Updater, this is a daunting task that will very likely break a lot of code (both internal and user code), especially for tools and packages that wish to be compatible with both pre-split UIElements and post-split UI Toolkit. So it was just a deferring of risk while we mature this new package-in-both-core-and-package-land workflow.
     
    uDamian, Aug 7, 2020
    #10

  11. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    1,090
    I can't see how this is a "deferring" or risk. By putting it off, because it "will very likely break a lot of code" will only get worse as time goes on. Much worse.

    Do you have a plan for how to handle a namespace change down the road? Or will the documentation simply be updated to read "The namespace for UI Toolkit scripts is UIElements (UIElements was the original name for UI Toolkit)"?
     
    SonicBloomEric, Aug 9, 2020
    #11

  12. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    331
    For the moment it will be limited to documentation updates, we're concentrating our efforts on the core requirements for supporting runtime UI.
     
    benoitd_unity, Aug 10, 2020
    #12