Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Question Future of UI Toolkit runtime UI authoring tooling friendliness

Discussion in 'UI Toolkit' started by optimise, Aug 25, 2022.

  1. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    I would like to ask any plan to make runtime UI authoring tooling to as user friendly as uGUI? From what I know, currently it's still quite hard and time consuming to create ui runtime like uGUI u can just drag the UI element to quickly resize it but at UI Toolkit u need to slowly type the value to resize it.
     
    DungDajHjep likes this.
  2. achimmihca

    achimmihca

    Joined:
    Feb 13, 2016
    Posts:
    279
    There is a visual editor for UIToolkit called UIBuilder: https://docs.unity3d.com/2021.2/Documentation/Manual/UIBuilder.html

    I think it is still an "experimental" package.
    Sadly, it has some flaws that make working with it fiddly, e.g. the object hierarchy folds on save and your current selection is lost.
    But still, I think it is better than nothing.

    @Unity, what are current goals / roadmap for the UIBuilder?
    My feeling is that it has all basic features (editing UXML and USS), but it lacks convenience (like not losing the selection on save).
    Are you in contact with customers (outside the forum) that use the UIBuilder?
    Has the UIBuilder the same prio as UXML and USS?
     
    Last edited: Aug 25, 2022
    DungDajHjep likes this.
  3. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    568
    It is complex to make a UI using the new tools.
    Forcing you to do things in a way that reminds me of web design.
    And I dislike the UI Builder tool.
    It may technically be better, but it is limited and not user friendly.

    If it had to be like web design, then it would be better to be like Wix or Weebly.

    It is not as intuitive as dropping stuff in the old canvas, moving and scaling them where you need them and having the whole thing being responsive. You could set up an entire screen in minutes and it works.

    Instead of designing the tool more like Photoshop, they did it more like Dreamweaver. It may be good for large studios that would perhaps hire a web designer to do that, but for small studios and teams with traditional UI artists (which I suspect is the more common Unity case) this is bad.

    The old system is much easier and friendlier for artists and designers.
    Most of the new tools Unity has introduced are opposing the original Unity tool design philosophy.

    Many of them have become more technical and more programmer friendly.
    Designers and artists do not script. Even if that is basic xml stuff.
    And they are not going to start doing it for Unity's sake.

    Contrary to that, Unreal is becoming less and less technical.
    Just dump stuff in the engine and they just work. This is how Unity used to be.
     
  4. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,105
    On the other hand for cases where UI Artists work only in Photoshop and programmers integrate UI into engine
    UXML file is faster way for programmers but it don't work with Builder

    Once you setup everything in uxml and open builder it will just kill everything and rewrite in some generator ugly way

    So question is: When UI Builder will stop killing everything and start edit only what changes like only add internal style, only change, name etc instead of rewrite entire UXML
     
  5. achimmihca

    achimmihca

    Joined:
    Feb 13, 2016
    Posts:
    279
    I don't agree with soleron. I feel that your arguments will not change with the future. Thus, I recommend taking a look at other engines.

    > It is complex to make a UI using the new tools.

    I don't think it is more complex (to use) than uGUI when creating UI.
    For me it is simpler and I can do stuff faster, because it is more like established web technology.

    > It is not as intuitive as dropping stuff in the old canvas

    The UIBuilder provides a drag'n'drop interface. That's only a matter of tooling.

    However, UXML and USS provide a language and mechanics that do not require a proprietary GUI application to create a UI.

    Similarly, you don't need Dreamweaver to create HTML.
    Same for Android XML layouts, Windows Forms XML layout, JavaFX XML layout, and others that implement the same approach.

    Futher, text editing has other advantages over GUI tools, for example, easy copy&paste, insert stuff, good for version control and diffs.
    There are existing, powerful text editors / IDEs that can be used to edit the UI, no need to reinvent the wheel.

    Futher, new tooling for text is implemented more easily, e.g., linters, static checks, etc.
    For example, you can easily write a test case that scans your UXML files to enforce some naming convention.

    In the end, having the UI as code, enables to work with it like code, re-use tools, principles, etc.
    The advantages have also grown into other areas, e.g. "infrastructure as code".

    When the language is present, the rest is only a matter of rendering it. That's Unity's main task.

    > And I dislike the UI Builder tool.
    Me too, it just feels unfinished, unpolished.
    But that's a matter of the UIBuilder, not of UXML and USS.

    > It may be good for large studios
    Unity is a big commercial company. I hope they focus on the needs of their customers.
    In a way, these "large studios" also pay for the many hobbyists that use Unity for free.

    > The old system is much easier and friendlier for artists and designers.
    I don't agree.
    Most I know and I also assume new designers (just finished with studies) have learned some web design basics, at least some CSS maybe HTML.

    > Most of the new tools Unity has introduced are opposing the original Unity tool design philosophy
    I agree.
    I really wonder if it would not have been easier to apply flex-box layout and stylesheets on top of uGUI. But now it's to late anyway...

    I agree, there is a huge conceptual difference.
    For example, you cannot just add a collider to a VisualElement like you would add it to a sprite.
    I wonder if Unity plans to overcome this conceptual difference somehow.

    Anyway, when only creating a 2D UI, without physics and other stuff, UIToolkit is fine.

    > Designers and artists do not script
    I doubt that.
    I think web designers either directly do HTML or CSS, or they deliver concepts to devs who have to implement them using HTML / CSS.
    Similarly for other XML and Stylesheet UI frameworks (Android etc.).

    But for game design, I think you are right.
    At least for previous Unity game design you are right, just because uGUI did not allow to edit stylesheets and layout XML. There war only drag'n'drop.

    > Contrary to that, Unreal is becoming less and less technical.
    This sounds great!
    I would definitely evaluate Unreal today (although I am not a fan of C++).

    But I wonder, if it is so great, why are people still complaining about Unity instead of moving to Unreal engine?
    soleron, why did you not change yet?

    > Just dump stuff in the engine and they just work. This is how Unity used to be.
    I never had this feeling with Unity XD
    I always had bugs coming from the engine. And the tooling, I was never too happy with it.

    At least with UIToolkit, the UI is much less painful for me.

    All that said, you might have guessed already: I am a developer with web design background, not working in game industry ;)

    ---
    This thread is already highly opinion driven. If this is the level of questions for todays "day with Unity UI team" then I am disappointed (but at least I was a part of it, yay! </sarcasm>).
     
  6. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    568

    I am using both engines.
    Depends on the project and the client. I am a professional, not a fanboy. ;)

    You will always have bugs coming from any engine.
    That is how software development is like.

    The question is, when was the period in time that you could set up your scene faster and with what version of what engine.

    This has changed drastically in the last few years as Unity tried to imitate Unreal because users were complaining, and on the other hand, Unreal tried to imitate Unity because... users were complaining.

    One was going up towards the ease of use that made Unity ubiquitous, while the other went down the complex path that was holding Unreal back from new user adoption.

    Unreal users were justifying Unreal's complexity and rigidness to "better structured production methods" which was a pure nonsensical elitist deflection. Unreal 5 got rid of a lot of the complexities of the past, removing decades of Unreal's outdated UX/UI baggage while unfortunately, Unity tried to emulate it to appeal to those people who were praising it.

    Obviously, that was an awfully bad decision as so many people today say that Unity has become more complex with a poor ROI considering the effort and bad PR. Pushed more towards Unreal.

    Funny you call this thread opinionated when
    A. You say you are not working in the game industry, so why do you have such confident opinion to start an argument?

    B. You said you have yet to try Unreal so how can you be so sure about your opinion?
     
    Last edited: Aug 26, 2022
  7. achimmihca

    achimmihca

    Joined:
    Feb 13, 2016
    Posts:
    279
    Ohh, I was just trolling.
    A lot of stuff in the forum reads more like complaining than questions.
    I had hoped for today to be more about questions.

    > Unity tried to imitate Unreal because users were complaining, and on the other hand, Unreal tried to imitate Unity because... users were complaining.

    I see. At least they try to learn from each other...

    Thanks for your thoughts on Unreal vs. Unity and how they developed. I didn't know that.
    Competition is good for the product. It seems, at least for Unreal ;)
     
    Last edited: Aug 26, 2022
  8. achimmihca

    achimmihca

    Joined:
    Feb 13, 2016
    Posts:
    279
    Coming back to the original question:

    > I would like to ask any plan to make runtime UI authoring tooling to as user friendly as uGUI?
     
    soleron likes this.
  9. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    I would like get reply from official. I really hope official can rethink about UI Toolkit authoring tooling for runtime UI and try to make it as user friendly as uGUI.
     
    soleron likes this.
  10. stefania_unity

    stefania_unity

    Unity Technologies

    Joined:
    Jan 27, 2021
    Posts:
    12
    Hey, thanks for sharing your feedback! The UI Builder balances the support of authoring via a visual editor while supporting authoring via code. When users need to collaborate, this gives them the freedom to work how and where they need to — obviously, with that comes some restrictions so that everything “plays nicely” together. Supporting code and visual editing both at the same time (and having a back-and-forth translation) can be a difficult balance to master, but with every piece of feedback we get and new features we release, we learn more and make adjustments.

    What artist-focused UI workflows are you expecting and hoping to see? There were a few comments touching on editing via the canvas (as you’d edit UI in the scene view while using uGUI), and while the UI Builder does support some canvas editing, we do have more work to do there. While software used for web tools (like Dreamweaver) utilizes literal selectors and classes, design tools like Figma or Sketch use shared styles which are similar in concept and there can be further improvements to narrow that gap in mental model. If you have specific ideas or examples of workflows you're expecting, please feel free to share.

    Since UI Toolkit utilizes flexbox, dropping items onto your canvas in the UI Builder will automatically be responsive since it follows a set of rules. You can always turn the position to
    absolute
    if you prefer your element to be moved freely. I understand this isn't the same as the anchors used in UGUI but pairing the position properties with selectors can be a pretty powerful way to ensure that the position of one element can be carried across multiple elements by updating just one selector.

    Additionally, I'm happy to say that we are currently making improvements to the Builder inspector to have more "visual" widgets so that the user has to interact with less text fields in order to edit values. Keep a look out for this in the future!
     
    soleron likes this.
  11. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    Currently the most wanted feature for me is uGUI like feature that I able to create UI element like Image and I can directly change its position and resize it freely at the UI element and UI Builder can auto and dynamically figure it out itself so I can have almost the same uGUI like authoring experience to create runtime UI easily.
     
    DungDajHjep and Catsoft-Studios like this.
  12. weiwei-at-unity

    weiwei-at-unity

    Unity Technologies

    Joined:
    Nov 6, 2020
    Posts:
    9
    Hi all, thanks so much for the discussion and feedback in the thread so far – I’ll do my best to tackle a couple of the specific points made throughout the thread.

    Can you expand more on this? Do you mean in the context of the UI Builder, or when authoring directly via UXML / USS or in code?

    The reason why the UI Builder handles the UXML this way is that it’s beneficial for workflows that need to support multiple people – it lets someone write via UXML if that’s more efficient for them, but also ensures that what they write can be further modified via the Builder for someone who prefers authoring in a visual editor.

    If there are specific things being overwritten in your code that you would otherwise like to preserve, or if there are bugs / issues with it, please let us know! Additionally, we’ve gotten feedback that it would be nice if something like comments don’t get removed, and we’re aware it’s something to look into.

    We actually fixed this bug!

    You can check out our roadmap here, which is where you can submit requests and bump existing ones. We try to bring minor improvements in every release but looking at bringing more impactful changes in future releases.

    As well, if you have any other feedback about the user friendliness of authoring in UITK, please feel free to respond to our survey. We’re always looking for feedback to help improve the usability and user experience of our tools!

    Yes, we work with customers in different market segments to better understand their needs

    We try to expose features uniformly across the three different layers: API, UI assets and UI Builder. Sometimes when we want to release something early in order to unblock users ASAP, we limit to API or UI assets level but typically we’d want to features to be consumable by everyone.
     
    mandisaw likes this.
  13. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    UI Builder for creating runtime UI. What I mean is currently seems like it's really tedious that u need to manually put the value at inspector to do all kind of resize and positioning. It's not like uGUI that u can just author the UI Element itself u created directly.
     
    soleron likes this.
  14. weiwei-at-unity

    weiwei-at-unity

    Unity Technologies

    Joined:
    Nov 6, 2020
    Posts:
    9
    Got it, thanks for elaborating. I would mostly point to what Stefania said above:

    Another aspect that we have considered is adding more authoring tools on the canvas directly, but no work is currently planned for it. If you'd like to bump it, you can do so here.
     
  15. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    568

    It is wonderful that you are thinking this way.

    I just wonder, based on what development experience, and which large teams' game development work do you decide/design how this new feature should be in order to fulfil the requirements you mentioned?

    Who validated the solution you provided to fulfil these requirements?


    As optimise said.
    Not just tedious, contrary to ANY tool that does design work. Positioning, scaling, these should happen freely.

    Not only does what you chose for users make design work unnecessarily rigid and mentally cumbersome, against several UX paradigms and good practices, but also makes it difficult to animate like you used to do before.

    All you had to do was enable the auto key for animation and scale or position the UI element exactly where and how you wanted it. And that was all. All a programmer had to do for you was run the animation "on click" with a simple script.

    Now this becomes cumbersome and increases the amount of back and forth between programmer and designer.

    A bad solution through and through as it removes control from the designer and gives the often-unpleasant task for the programmer (not to mention awkward and out of their expertise) to make aesthetic decisions.

    Increases production load, friction between the team members, and gives room for miscommunication and human error.
     
    DungDajHjep and Pier-Luc_Artisan like this.
  16. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,105
    just everything

    it is like write code in readable way and then it will be rewritten by codegen in totally unreadable form like full namespaces in names, ugly punctuation, etc.

    In my case I just define namespaces in root tag to write more compact and redable file
    write some space and empty line separator
    offering using tabs and many more code formatting things


    After opening builder everything gone
    Any tag that is legal from UXML point of view of don't known to Builder was deleted by builder.

    I think current approach to generate entire file is bad one
    Builder must change only sort of InnerHTML or OuterHTML but never entire file
    Just look how browser code builders work. They never change sources until necessary. We need the same behaviour from UI Builder to really work in both ways

    So current tool don't allow to work from code and builder only one or another never both.
     
    achimmihca and JoNax97 like this.
  17. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    We have clients shipping both large and small games right now using UI Toolkit. This also includes writing Editor tooling with UI Toolkit. We also have more and more internal teams converting Editor UI to UI Toolkit and giving us feedback from their experience.

    When it comes to how we decide what to work on next, it's a mix of "what will accelerate the transition away from uGUI and IMGUI" as well as "what will make the lives of existing UI Toolkit users easier". We have to balance an already large existing user base with the future users coming from other UI frameworks. But I can't be more specific than that because it depends on each feature and state of our resourcing (that cycle).

    As for "who validated the solution", we have our internal validation process but ultimately, it's you that decide. Nothing is written in stone. If it turns out it was a bad call, we'll change it. It's not like certifying an airplane. All the blunt feedback in this thread is valid and for the most part, it's well known. It just comes down to resourcing. Bare with us.

    On difficulty we have is that the UI Builder is NOT a design tool. It's not equivalent to Figma of Photoshop. At least, that's not its main purpose. UI Builder was created to make dynamic UI authoring easier. It assumes UI is dynamic by default, meaning there are no fixed sizes or even positions. Everything is relative to everything else. So if you change the font size across the whole of your UI, everything adjusts according to the rules you set. This is in direct conflict with the "let me resize everything manually directly in the canvas" approach. Manual control means we can't do anything for you once you want to go back and change something across many elements.

    As mentioned above, if you set the Position to Absolute, you can freely move and resize this element as you would expect in uGUI. You can even "anchor" it, though it's obviously not as easy as it is in uGUI. But when you're in this mode, we can't help you anymore when it comes to the layout. It's all on YOU. This was exactly the feedback we got against uGUI - auto layout.

    That said, it doesn't mean we don't want to bring the two worlds closer together. There's a lot more we can do to combine the auto-layout default of UI Toolkit with the ease of manual control that's great with uGUI. I just wanted to add some detail as to why we prioritized one approach over the other.
     
  18. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Just to add to the comments above, the reason for the hard reset when you open your UXML in the UI Builder is that the UI Builder does not work on top of UXML (text). The UIB works on top of the actual runtime in-memory asset that is created when UXML is imported. Obviously we don't want to parse UXML text at runtime, so when you import a .uxml asset, it gets imported as this VisualTreeAsset type. Since comments or whitespace are not relevant for the runtime, all of this information is lost when the asset is imported. This means that when you save the document in the UI Builder, we essentially generate brand new UXML text from this internal VisualTreeAsset asset. Your comments and whitespace is long gone.

    I just wanted to add a bit of background as to why things are how they are today. Of course, we fully agree this is a problem, but it's also a very difficult problem to solve and as such, difficult to prioritize.


    The namespace IS something we would preserve without a major refactor to be text-diff based. I'd suggest adding or voting for this in our roadmap page:
    https://portal.productboard.com/xvo...for?utm_medium=social&utm_source=portal_share

    Pretty sure this is a straight-up bug. Please report it when this happens. The UI Builder should never "corrupt" your UXML's actual tags, even if it doesn't support that specific feature of UXML yet.
     
  19. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,850
    I quit web designing in 2002. I don't want to go back there thanks. Borrrrring! Make the UI Toolkit work like a game engine component of Classical Unity. uGUI is fine. easy to teach to noobs, has world, camera and overlay modes which can be mixed and matched and is WYSIWYG. We have enough API's and different code stytes to cope with already. Stop adding complexity just because the new engineers you hired do not have experience in other than what is trying to be shoved down our throats as usable. It took me all of 5 minutes in UI Toolkit to deem it a sucker of my time and a rep killer on freelance contracts.. "You took how many days for that UI???"
     
  20. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    You are free to keep using it then. It will continue to be fine.
    No one is doing anything of the sort. We're even still officially recommending you keep using uGUI for runtime UI because we know UI Toolkit's usability is not there yet (for runtime).
    This implies you were able to accurately judge 7 years of continuous development and all future development in 5 minutes. Consider me impressed.
     
    oscarAbraham likes this.
  21. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,850
    I will consider you impressed to some degree as I seem to have triggered your smugness.. Now..howzabout returning to Unity's roots with components. No need to recreate React or whatever web framework. Betcha can't do it because you are stuck in your previous works paradigm. Prove me wrong.

    Five minutes was enough when you spent 10 years doing web XML/CSS/HTML and another 10 with building websites and applications from Flash using XML and a library. You may think yer forging forward with the style sheets and xml crud but yer trudging thru swamp best left a decade back IMHO.Full vector support shoulda been added to uGUI. It works like Classic Unity did and before you youngsters got around THAT was what made this engine popular. Not all this jiggery pokery from the web world and enterprise coding.

    As far as not shoving it down our throats..well i tried some Unity package or other that used it, installed the package and then tried to make me use it every time..tried to remove it and Plastic SCM would not allow it..some kinda dependency..Tried uninstalling it..no go.. Plastic said not allowed.. I had to get back to work. I had no use for the package but it was hoisted on me from another production ready package and then i spent backflips and wtfs trying to get rid of it to work and pay my bills again.
     
    Unifikation and Pier-Luc_Artisan like this.
  22. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Smugness implies pride. I was merely being sarcastic, with a hint of self-deprecation and bit of "please adjust your choice of words". I'm just as frustrated at how long this is taking as any user, if not more. But I also understand why it's taken this long.

    The point is that thousands of decisions, compromises, backtracks, and sheer hours went into UI Toolkit. There are areas we know currently (and maybe forever will) suck and there are areas we know are way better than anything uGUI can do (ex. sharing styles across many elements, or handling 1000s of elements on screen at once).

    There are also many areas where we chose NOT to do things like the web. If we truly just wanted to copy the web, we would just have embedded Chromium and called it day. What we wanted was to borrow some aspects of web UI authoring while creating something deeply integrated in Unity - and yes, that includes exposing UI Toolkit to GameObject/Components more and more.

    Another way to say it is: you can emulate uGUI with UI Toolkit (ie. have one GameObject/Component per UI element + author in the Scene), but you cannot emulate UI Toolkit with uGUI. What this means is that, at least in theory, we can get pretty close to uGUI pros while maintaining the UI Toolkit pros. But the opposite was not as feasible - to add UI Toolkit's pros into uGUI. Same goes for IMGUI. This reality is what drove UI Toolkit's initial creation.

    True, this will become more and more of a friction. As packages and tools slowly move to UI Toolkit, or even UI Toolkit-only, it will become increasingly difficult to ignore UI Toolkit. Which is why we fully agree that we need to bridge the current gap in functionality and workflow. But it's also why I hope you give UI Toolkit a bit more than "5 minutes" before dismissing it entirely.
     
    useraccount1 likes this.
  23. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    568

    Obviously, and what many of us say is that his is a BIG mistake.
    This is our feedback.

    To which your response is that our assessment that it is not designer friendly is correct, which that contradicts others from your team claiming that the UI Builder was made with improved collaboration between coders and designers in mind which is obviously not the case.

    To be honest, I am not even sure coders like it.
     
  24. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Improve does not have to mean "fully solve".

    On the Editor side, compared to IMGUI (which is C#-only), we've improved designer/code collaboration quite a bit (from zero).

    On the runtime side, compared to uGUI, I still think the experience is better for designers that don't already know Unity. You no longer have to teach a full-time designer how to deal with GameObjects, MonoBehaviours, Prefabs, etc. They just have to learn UI Builder (and true, a bit of flexbox layouting). And if they really want to use another design tool and just place every VisualElement in the UI Builder with Absolute position and size on top of a screenshot of their final design, they can do just that.

    Even more, if you higher designers straight out of any web development shop, they can much easier hit the ground running with UI Toolkit.

    But yes, if you compare UI Toolkit / UI Builder to uGUI, as someone that knows a lot about uGUI and Unity, you're going to find a lot missing. You're right. This is why we still continue to maintain uGUI while we work to close the gap with UI Toolkit.
     
    zombiegorilla likes this.
  25. DungDajHjep

    DungDajHjep

    Joined:
    Mar 25, 2015
    Posts:
    201
    I also gave up after 5 minutes, looks like someone hired web developers to develop Unity features.
    Haha just kidding, although UIToolkit has quite a few useful features through something like CSS. But unless it also provides simple operations like UGUI, no game developer will waste time on it. All of Unity's sample projects are also using UGUI and I'm sure the development team feels the same way.
     
    Unifikation and ippdev like this.
  26. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,850
    So..yeah..essentially you ignore the millions who do all their own apps from end to end to cater to some who may bring on a web developer to "design" their UI. Pointless. They want to work in Unity then learn the program. Tired of other industry workers hogging in, applying their industry methods and bloating the app and killing component based WYSIWYG workflow.
     
  27. zombiegorilla

    zombiegorilla

    Moderator

    Joined:
    May 8, 2012
    Posts:
    9,042
    OR... make the text fields more user friendly. There are times when I want to manually enter, padding for example. Click in field, enter value, tab, tab, tab, value, tab, tab, tab, value,tab, tab, tab, value. Tabs should take you to next most common field in workflow. Certainly tabbing to label is not needed. ;)
    Also a little better round trip with text editor so things don't get out of whack.

    I have stated my opinions on UITK before. I like it, it is a smart direction and it makes sense. My engineers love it as well. Our only challenge to full adoption right now is the performance. Its nearly equal to ugui, but still a bit slower. But there is a ton of things you do in ugui to boost performance. UITK seems a bit "as-is" at this point. Better performance (than uGUI) and we are all in.
     
    SolidAlloy and DungDajHjep like this.
  28. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,606
    As someone who is half artist, half coder, I love UI Toolkit. I think the way I can either design in the builder, or code my own visual elements, is far better than the mess of having to try and edit rect transform game objects in a normal scene.

    I genuinely hated working on UI using uGUI (which is what I learnt at first when UI toolkit was much earlier in development). Now I can slap together UI (editor or runtime) about 100x quicker. I'm definitely glad to have it over IMGUI when it comes to editor tooling.

    I think once I can reference other visual elements and unity objects in the UI builder, that covers most everything I want out of it (which I believe are on the road map).

    Feels like there's a few people here who would rather complain about UI Toolkit than take the time to really knuckle down and learn it. It probably took me a couple of months to unwind the usual 'game objects and components' expectations and get comfortable with UI Toolkit. Now I'm not going back.

    And not like it's going to replace uGUI, as noted. Same as DOTS isn't going to replace the usual Unity work-flow.

    Definitely agree with the gorilla above, though. Please fix tabbing through the UI Builder!
     
    MousePods likes this.