Mixedrealitytoolkit-unity: Clean up MRTK inspector dependencies

Created on 17 May 2019  路  8Comments  路  Source: microsoft/MixedRealityToolkit-Unity

Describe the bug

Prior to merging the new UI, it was possible to edit MRTK profiles without an MRTK instance in the scene.

This is no longer the case since https://github.com/microsoft/MixedRealityToolkit-Unity/pull/4314 was merged yesterday
image

To reproduce

Try to edit and MRTK profile without an active instance in the scene.

Expected behavior

It should be possible to edit MRTK profiles without having an instance in the scene.

Your Setup (please complete the following information)

  • Unity Version 2018.3f1
  • MRTK Version v2 latest dev

Target Platform (please complete the following information)

  • HoloLens
  • HoloLens 2
  • WMR immersive
  • OpenVR
4 - In Review Bug Profile and Inspectors

Most helpful comment

Some rules of thumb I think we should consider when reworking these profiles:

  • First ask ourselves why this profile needs an instance to display its data and whether we can avoid this requirement altogether.
  • When an instance really is required for a profile to function, don't just exit early if no instance is found. Display as much of the data as possible.
  • Replace sections that can't be displayed with a standardized helpbox warning explaining that this section of the profile requires an instance, and offer a button to create an instance on the spot.

All 8 comments

To summarize discussion extended in the PR referenced above, the MRTK inspectors need to be updated to only block rendering/editing when that particular profile requires an MRTK instance in scene. Or conversely to allow a design such that ALL profile inspectors do not require a MRTK instance at all.

Before the PR, some profiles were blocked under certain conditions or although would render, they would not actually drive any editing value as they were not hooked up to their serializedobjects in OnEnable(). The PR made this non-obvious disability 1) universal and 2) more visible to the user.

Some rules of thumb I think we should consider when reworking these profiles:

  • First ask ourselves why this profile needs an instance to display its data and whether we can avoid this requirement altogether.
  • When an instance really is required for a profile to function, don't just exit early if no instance is found. Display as much of the data as possible.
  • Replace sections that can't be displayed with a standardized helpbox warning explaining that this section of the profile requires an instance, and offer a button to create an instance on the spot.

@Troy-Ferrell Classic cross-posting, haha. Clearly we're on the same page.

Indeed, also point to mention for record, when the inspectors require a MRTK instance in scene to function properly, the instance many times MUST be it's own. Example: When editing the speech commands profile, this looks at what input action mappings are available....but it needs to look at the input actions for the instance in which it is the assigned speech profile.

Also the back button when on a sub-profile inspector turns out has always been broken. It returns back to the ACTIVE parent which is not necessarily that profile's parent. For example you could create a speech profile but not assign it to any input profile

@Railboy, can you give an example of a profile that _needs_ an MixedRealityToolkit instance to render? We should strive to eliminate that need since systems should be fully usable without this instance (once #3545 is complete -- which it very nearly is)

@davidkline-ms , I believe it is the same single dependency everywhere atm. Certain profiles rely on the available input action mappings (action Ids & labels) and right now this can only be attained via the current MRTK instance. Look at the speech profile inspector for an example.

Of course, this is actually a bit troublematic still since a speech profile could technically be referenced by multiple input system profiles (let's say different scenes or something) and of course technically, each input system profile could have unique action mappings, although this is an edge case

@Troy-Ferrell , what PR solved this? I'm hitting it currently in PointerClickHandlerInspector with what I think is the latest from mktr_development (043a4facf532be2596c23cdeb3a7fc2e6073565b).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dfields-msft picture dfields-msft  路  3Comments

StephenHodgson picture StephenHodgson  路  3Comments

dustin2711 picture dustin2711  路  3Comments

reillydonovan picture reillydonovan  路  3Comments

brean picture brean  路  3Comments