← 返回首页
`MenuController` base class for the UI Toolkit · Issue #69 · UnityCommunity/UnityLibrary · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

MenuController base class for the UI Toolkit #69

New issue
New issue

Description

Hello, I want to propose adding a system that I have implemented in previous projects of mine that use the Unity UI Toolkit.

It consists of a base class MenuController which is linked to a UXLM document or a Visual Element (the view). When inheriting from it, allows you to add a new attribute I've defined called QueryFromView applicable to fields of type VisualElement (or subclasses) so that field is automatically initialized to an specific element from the view.

You can query by name, type, or both.

It counts with explanatory error and warning logs for every possible misuse of the system.

Depending on the project, I use two different variants:

Variant 1: EditorWindow and controller are independent

When using this option, whenever you inherit from MenuController you have to inherit the base constructor in your class, like this:

You initialize your controller this way (unless you've added extra arguments to your constructor), where visualTreeAsset represents your view as a UXML document:

Variant 2: EditorWindow is the controller

When opting for using this variant, you don't have to worry about constructors or inicialization. However, you have to worry about dragging the UXML file that represents your view from your EditorWindow script to the Menu UI field in the inspector.

Note that this variant does not allow you to use as a view a VisualElement that is not represented by a UXML file.

Does it sound useful for your repository? In case you like it, which variant should I implement? Please let me know what you think about it.

PS: Don't mind the namespaces and spanish comments. I used screenshots from a time I shared my system in a Spanish-speaking community.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    • Open in GitHub Copilot app

    Footer

    © 2026 GitHub, Inc.