slluis
commented
4 years ago Closing, original PR was closed.
Closed monojenkins closed 4 years ago
slluis
commented
4 years ago Closing, original PR was closed.
THE FEATURE IT'S IN PROGRESS PLEASE DO NOT MERGE
This PR adds a new mechanism to create our own keyloop system to sync Gtk and Cocoa world focus chain.
Basically right now VS4Mac is a Gtk application which recently added a way to include embeded native views based in a hacked gtkquarz window which it has this structure:
Under the hood this native views are overlapped on top of Gtk and synchronized with a Gtk view container host (GtkNSViewHost)
In VS4Mac is the Gtk application is who captures the keypress events and the CommandManager ensures if the selected view is a native view it tunnels the event to cocoa world (making stop the escalation of the event in the Gtk) or otherwise it continues the gtk event flow.
Actually we were doing this tunneling to cocoa in a incomplete way, we were only calling to ".OnKeyDown" from the focused view, which it doesn't match the same behaviour as pressing a key in a cocoa application which also affects to the tab key navigation (Keyloop) mechanism.... and this the reason we were getting some unexpected behaviours in this case.
To try to fix this, I checked a lot of documentation, but it seems there are not much information about how this works under the hood or how replicate it... and after a lot of tests didn't found any good way to do it more easily... that's because I decided to rewrite current implementation to create our own mechanism to calculate this keyloop calculation.
The current cocoa view structure described above adds more complexity to our implementation, first because all the native embeded views shares the same NSWindow (GtkQuarzWindow) and this means when the NextKeyView is not set in a native view, the NSWindow autocalculates the next or previous element, and this could be or the correct next view or the first GtkQuarzView or another view from another embeded view, and that's because pressing tab in the old implementation press tab was giving us randomly unexpected (wrong) results.
Another problem we had was how connect the Gtk focus chain to Cocoa, that's means we needed to handle cases when user press tab and next view is a GtkNSViewHost then calculate which is our first candidate for item focus.. and ... the same for pressing SHIFT+Tab (focus last item from this embedded view).
And.. sorry about the hack.. but didn't found any idea about how do it in a better way living into a Gtk application :-(
Fixes #1001596 - A11Y_Xamarin Designers_Property pane_keyboard : User is unable to navigate from property filter to the next controls inside property panel window https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1001596
Backport of #9267.
/cc @sevoku @netonjm