-
-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: menu name may use string field #1008
base: main
Are you sure you want to change the base?
Conversation
Perhaps a better way to handle this would be to have the label default to the gameobject name when the field is empty? |
We could also only show the preview if the text contains |
Editor/Inspector/Menu/MenuItemGUI.cs
Outdated
if (!needsRichLabel) | ||
{ | ||
EditorGUI.BeginChangeCheck(); | ||
EditorGUILayout.PropertyField(_name, G("menuitem.prop.name")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're linked, we should just show the name property (which can link directly to the GameObject if this is a ModularAvatarMenuItem
). If we're not linked, we should show the label field always (and conditionally show the rich text preview).
Editor/Inspector/Menu/MenuItemGUI.cs
Outdated
{ | ||
EditorGUILayout.PropertyField(_prop_label, G("menuitem.prop.name")); | ||
} | ||
var linkIcon = EditorGUIUtility.IconContent(needsRichLabel ? "UnLinked" : "Linked").image; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This UI class can be used to render VRCExpressionMenu controls out of expression menu assets as well, in this case the link icon doesn't make sense, as there's no GameObject to link to. See the MenuItemCoreGUI(GameObject parameterReference, SerializedProperty _control, Action redraw)
constructor for details.
Editor/Inspector/Menu/MenuItemGUI.cs
Outdated
EditorGUILayout.PropertyField(_prop_label, G("menuitem.prop.name")); | ||
} | ||
var linkIcon = EditorGUIUtility.IconContent(needsRichLabel ? "UnLinked" : "Linked").image; | ||
var guiIcon = new GUIContent(linkIcon, S(needsRichLabel ? "menuitem.rich_text.toggle_off.tooltip" : "menuitem.rich_text.toggle_on.tooltip")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can just enable this when you type a <
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this option doesn't directly control rich text, but rather whether we're linking our name to the gameobject, so the translation key (and text) should probably reflect that.
Editor/Inspector/Menu/MenuItemGUI.cs
Outdated
if (EditorGUI.EndChangeCheck()) | ||
|
||
EditorGUILayout.BeginHorizontal(); | ||
var needsRichLabel = (!string.IsNullOrEmpty(_prop_label.stringValue) || _isTryingRichLabel); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be simpler to just do _isTryingRichLabel |= !string.IsNullOrEmpty(_prop_label.stringValue)
?
EditorGUI.BeginChangeCheck(); | ||
EditorGUILayout.PropertyField(_name, G("menuitem.prop.name")); | ||
if (EditorGUI.EndChangeCheck()) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One note: Please make sure this doesn't break in some terrible way when multiple items are selected...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm stuck on this, I can't figure out how to properly handle multi-editing. Best I can do right now is to maintain the current behaviour where it just edits the GameObject name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's maybe better to multi-edit the label field in that case. Seems like less surprising behavior than editing the name of all the GameObjects at once?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be current behaviour as of the latest commit
For the next commit, I had to rebase to 1.10.0-rc.4, because it was not possible to test Sub Menu of source Expressions Menu Asset on the base I started on |
3622606
to
e4d7d8b
Compare
- Rebased to 1.10.0-rc.4 because the inspector of SubMenu of source Expressions Menu were broken in the base commit this branch initially started with, which was preventing testing some aspects raised during review. - When this is being rendered as part of an SubMenu of source Expressions Menu, don't use any of the label logic, as menu items within such an Expressions Menu are not backed by any GameObject. - Rename _isTryingRichLabel to _useLabel. - Since switching to unlinked always overwrites the label field with the current ObjectName, and switching to linked always empties the label field, the state of _useLabel while the Inspector is open is implied by the value of the label field, or the previous state of the _useLabel field itself when the label field is being emptied out. - In addition, use the |= operator. - When the name is linked, and the user begins typing the "<" character, set the label field, and do not apply the name. This will automatically switch to linked mode as the inspector will be reevaluated a second time. - If the original object name already contains a "<" character (i.e. it comes from a previous version of Modular Avatar), there will be no automatic conversion happening as long as the object name still contains the "<" character. - Changed the localization keys to discard the rich text toggle aspect. - Not addressed: When multiple Menu Item components are selected, the behaviour of the inspector currently edits the GameObject name, with no link button, and no automatic conversion when typing "<", regardless of the contents of the label field.
I like that. Great idea ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the patch! I'll include this in the next minor update (1.11) - probably in the next week or so?
Note that there's a minor bit of UI weirdness that might be good to fix while waiting - see my comment below.
if (GUILayout.Button(guiIcon, GUILayout.Height(EditorGUIUtility.singleLineHeight), GUILayout.Width(25))) | ||
{ | ||
_prop_label.stringValue = !_useLabel ? _name.stringValue : ""; | ||
_useLabel = !_useLabel; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's some confusing behavior that occurs when you do the following:
- Unlink a menu item
- Update its name
- Relink it by clicking the link button
Expected behavior: The displayed name in the inspector should match the game object name.
Actual behavior: The displayed name in the inspector is the old label value, until you change focus away from the name field (at which point it'll reset to the gameobject name).
This is a proposal to include a new "label" field in Modular Avatar Menu Item.
Although not specified, menu items may contain line breaks and rich text, which will be displayed in the radial menu.
It is currently really awkward to write rich text within the object name. In addition to being long, rich text tags will contain a forward slash
/
and other symbols.Exposing that field may enable other inventory automation tools to more precisely control the generation of the expression menu items.
This PR attempts to add the following:
The UI method is currently unsatisfactory, I do not know what would be a good fit. Most users will not use rich text, so the current proposal hides the existence of that new field to the user unless they click a "Rich text" checkbox, which temporarily enables the visibility of the field even when that field is an empty string.