Mixedrealitytoolkit-unity: Diagnostic view does not enable/disable when project is running.

[SimonDarksideJ]

Does this affect the legacy HoloToolkit (master) or the Mixed Reality Toolkit (mrtk_release)?
Mixed Reality Toolkit

Describe the bug
If the Diagnostics are set to visible while the project is running, the view does not display

To Reproduce

• Enable diagnostics in the configuration profile
• Create a new Scene
• Click Mixed Reality Toolkit > Configure
• Enter play mode.
• Set Visible to True in the diagnostics profile.

Expected behavior
The diagnostics window will appear
(correspondingly, if turned "off" it should disappear)

Actual behavior
Nothing happens

Unity Editor Version
2018.2.13f1

Mixed Reality Toolkit Release Version
2018.9 Beta

[davidkline-ms]

Best of my understanding is that profiles are read at system startup. Code that wishes to change values during runtime should be talking to the system through its interface.

I believe the issue here is that the diagnostic system defined read-only properties instead of allowing runtime changes.

I'll make the appropriate changes.

[SimonDarksideJ]

Your basis is incorrect @davidkline-ms , all systems and profiles are designed to be able to be configured while the project is running. Also the scriptable config system has been designed to react when the user swaps out a profile at runtime.

The only exception to this is the InputActions profile, due to the ID's used can't be changed while the project is running.

[davidkline-ms]

The systems that I am familiar with read the profile during Initialization and the app code references the runtime class (via the interface) properties to access. Is there an example where the system interface does not expose the profile settings via a property and requires client code to access the profile directly?

It feels like that is an undue burden on the clients when the systems can easily expose the profile properties (similar to the spatial awareness system).

[StephenHodgson]

The systems that I am familiar with read the profile during Initialization and the app code references the runtime class (via the interface) properties to access.

If this isn't true... we should change it. We should always use profile data. We're data driven by design.

[keveleigh]

Do you have an example of a system implementation that continues to read from the profile after initialization?

[davidkline-ms]

Is there an example where the system interface does not expose the profile settings via a property and requires client code to access the profile directly?

[SimonDarksideJ]

Those are certainly good points @davidkline-ms and worthy of discussion. The original systems were designed around:

• Hot swap capability - the ability to swap out profiles at runtime to effect new behaviours
• Runtime configuration - the ability to manage a running service.

Likely during the beta we need to review these practices based on the current state and agree the way forward for review.

[davidkline-ms]

From what I can see, when a new profile is loaded, the system will get a Reset() call. This will reinitialize with the new settings.

At that point, it is not clear (to me, at least) how the client code becomes aware of the state change. Perhaps we need a "system [re]initialized" event that all clients can subscribe to.

[StephenHodgson]

Perhaps we need a "system [re]initialized" event that all clients can subscribe to.

That's what Reset() is for

[davidkline-ms]

That's what Reset() is for

By my read of the code, client scripts do not receive a reset notification. I am proposing we provide an event that client scripts can register for that informs them that reset has been called on the specific service.

[StephenHodgson]

Not sure an event is required since every service already has the required method implementations.

[davidkline-ms]

Not sure an event is required since every service already has the required method implementations.

There are likely scenarios where an application may need to know that a system has been initialized / reset and respond accordingly.

Design wise, I envision a single event something like this:

void OnSystemInitialized(IMixedRealityService systemInstance)

This would enable client code to react to the change and (potentially) update existing objects to reflect the changes in the specific system (for example, the desired material or model).