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

Unity Engine
,
1

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.

1 Like
2

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.

2 Likes
3

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 ^^'.

2 Likes
4

+1

Is there a roadmap on when we will see these APIs starting to become public?

5

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.

2 Likes
6

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 :smile:

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).

1 Like