-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Converted GazeInteraction project from C++ to C#. #3427
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
Conversation
Thanks azchohfi for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
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.
🚀 🚀
Two awesome things about this PR:
|
3d5d324
to
eff69f8
Compare
@azchohfi just tested in the sample app and was working great! For some reason the store app interaction traction wasn't working for me, but worked perfectly here with the new code! 🎉🎉🎉 |
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.
Hey @azchohfi some initial feedback on the port. I think there's a few things we could take the opportunity to improve with the change to C#. Feel free to just say that we should file issues for future improvements on things. There definitely did seem to be an issue with ComboBox though.
Haven't quite completed looking at everything, but figured this would get us started again on trying to wrap this up. Thanks!
Microsoft.Toolkit.Uwp.Input.GazeInteraction/DwellInvokedRoutedEventArgs.cs
Outdated
Show resolved
Hide resolved
Microsoft.Toolkit.Uwp.Input.GazeInteraction/DwellProgressEventArgs.cs
Outdated
Show resolved
Hide resolved
|
||
namespace Microsoft.Toolkit.Uwp.Input.GazeInteraction | ||
{ | ||
internal class ComboBoxItemGazeTargetItem : GazeTargetItem |
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 added a ComboBox to the example:
<ComboBox SelectedIndex="0" Margin="100,100">
<x:String>One Thing</x:String>
<x:String>Two Things</x:String>
<x:String>Three Things</x:String>
<x:String>Four Things</x:String>
</ComboBox>
However, while it opens the combobox, it doesn't show the cursor or allow me to invoke item selection with it. Is that because we're missing the XamlRoot
now or something else?
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 this is related to XamlRoot. Not sure what is happening. What was the behavior on the old version?
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.
The old version wasn't working for me at all, so I couldn't compare... @peteams was the cursor supposed to move to the pop-up element and show in the drop-down?
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.
Alright, so investigated this a bit. The old code did a better job with the highlight rectangles on the ComboBox, even though I've fixed that now in the C#, the code is the same within the GazeTargetItem.RaiseProgressEvent
method, so I'm not sure why it behaves differently, though maybe has to do with how the visual tree is searched in that logic? Doesn't seem to make a difference using x:String
elements vs ComboBoxItem
elements directly in my example above.
I am basically noticing that sometimes it does find the ComboBoxItem and can select it, other times it shows the highlight rectangle briefly, but most times there's no visual indications (the cursor is behind the pop-up too), and it seems like the UIElement selector is grabbing the 'TextBlock' element within the ComboBoxItem instead of looking up and grabbing the ComboBoxItem itself, this I think is the main thing breaking the logic here. Will try and poke a bit more, but may be easier to have someone from @peteams group take a look and help us with this fix.
Since this also wasn't working great in the C++ version, I think we should just add it to our #3497 list or a separate issue, and not block this PR. I think the PR should be good to go otherwise.
// Setup a new app service connection | ||
AppServiceConnection connection = new AppServiceConnection(); | ||
connection.AppServiceName = "com.microsoft.ectksettings"; | ||
connection.PackageFamilyName = "Microsoft.EyeControlToolkitSettings_s9y1p3hwd5qda"; |
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.
Is this the system app? Is this documented somewhere we should probably have a comment? FYI @peteams
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 couldn't find docs for this anywhere.
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.
From an internet search, it almost appears like it's grabbing from an app service that's only from a sample here:
<Extensions>
<uap:Extension Category="windows.appService">
<uap3:AppService Name="com.microsoft.ectksettings" SupportsRemoteSystems="true" />
</uap:Extension>
</Extensions>
@joncamp do you remember what this is about? It's unlikely for someone to compile and install this other sample app locally. Should we bother having this extra code in the Toolkit? It seems like it's not referenced anywhere within the codebase itself?
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.
@azchohfi since this is already working better than what was in the Toolkit, should we merge this and open an issue to track the ComboBox problem separately? |
I believe we should, yes. |
As an extra precaution against accidental merge
@azchohfi any idea why I'm seeing the output directories in this project? Is this if I don't clean when switching from the C++ project? |
It might be, but it's fine to see those files there, they won't be built or anything. |
Think all the minor details are smoothed out enough for this PR. Should follow-up on the Settings with the Gaze team as well as a general review, and later as another PR we should fix the ComboBox behavior for #3497, and investigate tidying up some code and performance with our VisualTree investigation as part of #3487. It'd also be good to know if we can mimic these Gaze events with WinAppDriver or other tooling so that it's easier to try and reply specific scenarios for debugging and testing. |
@azchohfi package step failed now? |
Oh, that is the design package that is not updated properly. I can fix that. |
Seems to be 00:00:00 a lot?
…yncAction, to keep this from being a breaking change.
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.
Let's move ahead and we can fix anything else in the future, but pretty sure we're in the same space we should have been with the C++ version.
Hello @michael-hawker! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Unifies Toolkit language to be only C#.
PR Type
What kind of change does this PR introduce?
What is the current behavior?
C++, boo.
What is the new behavior?
All C# 🦙🎉
PR Checklist
Please check if your PR fulfills the following requirements:
This is not exporting WinMDs, so C++ devs will be stuck on 6.x, and this is expected.