-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Move input subsystem implementations to the input package. #11641
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,6 +3,7 @@ | |
"rootNamespace": "Microsoft.MixedReality.Toolkit.Speech.Windows", | ||
"references": [ | ||
"Microsoft.MixedReality.Toolkit.Core", | ||
"Microsoft.MixedReality.Toolkit.Input", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems weird. (I don't think we should move these base classes, but if they need to be moved) I'm not sure why the speech classes weren't moved into the speech package. That's where the concrete implementations already live. |
||
"Microsoft.MixedReality.OpenXR", | ||
"Microsoft.MixedReality.Toolkit.TextToSpeech.Windows" | ||
], | ||
|
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 don't think these classes make sense to move (apologies for being less certain before: I though you were referring to layer 3 but were actually referring to layer 2, below).
There are three defined parts to an MRTK subsystem:
1 and 2 should live in the Core, imo, because devs shouldn't need to write the scaffolding themselves or have to import the Input package just to get access to the scaffolding. There's almost no variation in this level, and any needed variation could/should live in the concrete implementation.
3 is where the actual interesting differences lie, and the only level devs should need to write themselves (if they don't want to use MRTK's impl).
The existence of the interface is slightly misleading. I don't believe Unity's pattern for subsystems typically defines explicit interface types, but we used it just to maintain an API consistency across subsystems and their providers.