Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Unite 2023 Registrations are now LIVE! We are thrilled to announce that Unite 2023 Registration is now live and open for all!
    Dismiss Notice
New Forum User Notice Unite 2023 Registrations are now LIVE!

Question Why so many `internal` things in UITK and why not providing more tools to extend it?

Discussion in 'UI Toolkit' started by ldubos, Aug 27, 2023.

  1. ldubos

    ldubos

    Joined:
    Oct 14, 2014
    Posts:
    33
    Hi, I'm currently working on an "ExtendedVisualElement" where I add some missing feature that I need for my project like shadow-box, gradients etc. but I need to use a lot of tricks to just being able to get the correct borderRadius of an element, why the computedStyle property is internal? Why MeshGenerationContextUtils is internal? etc. etc.

    I found that almost every tools which can be useful for thoses who try to extend UITK are all internal, it's almost impossible to customize/extend UITK, why we can't create CustomStyleProperty which take StyleLength type? Or why we can't just extend the parser?

    I really don't understand this choice to have almost every useful types/functions internal in UITK.
     
    ldubos, Aug 27, 2023
    #1

  2. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,203
    Hi. I understand the sentiment. I often run into this myself. The reason we have so many APIs set to internal is that they are simply not ready to be public yet. Making an API public requires it to meet certain standards, have proper docs, be robust against all possible use cases, and not change (ever, ideally). There's actually a lot of examples of APIs we made public and regretted it as we are now stuck with them and will require major breaking changes to fix. Internal APIs give us a bit more flexibility by allowing us to make changes on them and iterate. We'll slowly make these public as they mature.
     
    uDamian, Aug 28, 2023
    #2
    MousePods likes this.

  3. ldubos

    ldubos

    Joined:
    Oct 14, 2014
    Posts:
    33
    Thanks for your response. Would it be possible to expose more functionalities, perhaps under a designated namespace like "UnityEngine.UIElements.Experimental," to signify that these functions are not yet stable?

    From my perspective, the biggest issue right now is the difficulty in utilizing UITK for niche use-cases. For instance, I'm trying to implement nested tooltips. Ideally, I'd use a link tag within a Label and retrieve the tag's position via PointerOverLinkTagEvent. However, this function only returns the pointer coordinates, not the tag's bounding box. But my goal is to center the tooltip below the link for design reasons and for the sake of the UX.

    Since UITK lacks inline-block support, using large text sections with interspersed tooltip text elements disrupts line breaking, as elements are rectangular by default. To work around this, I'm forced to split the original text word by word, to ensure the correct behavior and obtain the tooltip text bounds. And this is one of the simpler cases.

    I would much rather work with an unstable API that grants me the freedom to achieve my goals, than with a "locked" API that necessitates the use of reflection or other risky workarounds for basic component customization, such as getting the correct borderRadius ^^'.
     
    ldubos, Aug 29, 2023
    #3
    ontrigger and _geo__ like this.

  4. _geo__

    _geo__

    Joined:
    Feb 26, 2014
    Posts:
    1,111
    +1

    Is there a roadmap on when we will see these APIs starting to become public?
     
    _geo__, Aug 31, 2023
    #4

  5. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,203
    We have done this in the past. All of UI Toolkit used to be in such a namespace, and we even have a few such APIs still present (related to animation/transitions). The problem with these Experimental (but public) APIs in practice is that, regardless of messaging, users quickly assume the same stability from them as any other public API. When it comes time to break them, as we said we would, the pain in user projects is equal to any other public API change. What we make public and what we keep internal is tied to trying to keep a balance between support burden and capability improvements.

    No hard dates at this time. We're currently focusing on finally eliminating the parity gap between UI Toolkit and uGUI, which means a little less (but not zero) time on incremental improvements of existing APIs.
     
    uDamian, Sep 22, 2023
    #5
    ldubos and _geo__ like this.

  6. _geo__

    _geo__

    Joined:
    Feb 26, 2014
    Posts:
    1,111
    Thank you for your comments. Is there a place where we (as a developer community) can/should gather what parts of the API we would like to be moved to public? It all seems so fragmented here on the forum. Are there some roadmap docs for us to peek at :D

    Could you also elaborate a bit on how your decision process works?

    I have been making some UI Toolkit Assets recently and while journeying into the UI Toolkit depths I have kept a list of things that I would like to share from an Asset dev perspective (thanks for making the source available btw.). I had to use a fair bit of reflection code to make it all work (UI Builder). I do support Unity 2021, 2022, 2023 and I noticed that some parts of the internal APIs have not changed in any of these (some of them are good candidates for being made public imho).
     
    _geo__, Sep 22, 2023
    #6