@Maurizio
Thank you for your feedback! :)
I think Marc has explained more acuratelly than me the problem.
@Marc
Thank you for your explanations. It is clear that I did not explain myself
well enough. :)
One thing I did not mention and I think it is important. The solution that
I've discribed in my first email will not affect in any way how actions are
handled. They will follow the same path of functions that they do at the
moment. The only thing that will change is how they are triggered, or
better said, the context in which they are triggered.
Regarding your questions:
>Personally, I wouldn't care if clicking in Inspector (or MuseScore
>Connect) *did* transfer focus there completely. It's really only the
>toolbars where this definitely should not happen. So that's presumably
>another option.
Yes, it is an option, but Lasconic said that he doesn't want this to
happen. Also for the toolbar, I've made so that focus is transfered there
only via tabbing, clicking doesn't.
>Would this also extend to Ctrl+Arrow, Shift+Alt+Arrow, etc?
No, for 3. just very sensitive keys like Tab/Shift+Tab (even if it's not a
shortcut at the moment, this doesn't mean it cannot be added by a user),
Return, Arrow key (but not their combinations); keys that are used by most
of the controls in Qt and for which the user knows exactly what is supposed
to happen when they are pressed. These are just of the top of my head.
>But you are right that it would be nice to be able to navigate Inspector
>via keyboard even if initially entering it via clicking. Not sure, but I
>*think* this could be made to work. By default, I assume pressing Tab
>would put focus on the first toolbar button, but maybe the code could
>check to see if something else is "active" and instead transfer focus
>there. Andrei?
Here there are two solutions:
One is by default implemented by Qt, everything that has the TabFocus
policy will be added to the tab order. So if I just change the focus policy
for the inspector's elements to TabFocus, when tabbing, when you get to the
end of the toolbar, it will jump directly to the inspector.
The other is the one that we've talked about last week I think. A shortcut
that will change the focus from one subwindow to another so when I start
tabbing, it be limited to the elements of that subwindow. As I said before,
this second one is a bit tricky to be done, but I've thought of it a lot
and I've come up with a general idea and when I finish with this problem I
will start to make some tests for it. As shorcut, the Windows guidelines
for Keyboard UI navigation[0] say the following:
The TAB key moves the input focus to the next area of an active pane only
if it is not used by any other controls within the window.
The CTRL+TAB shortcut keys or F6 function key moves the input focus to the
next pane or palette.
The CTRL+F6 combination moves the input focus to the next window in a group
of related windows or between multiple-document interface (MDI) windows.
Since CTRL+TAB is used for changing from one tab of score to another,
CTRL+F6 is the next best thing.
For the moment, in my code, I've deactiveted tabbing for everything else
except for the toolbar until I add the propper screen-reader feedback, I
arange the tab order and we decide which of the two solutions I should
implement.
[0]
http://msdn.microsoft.com/en-us/library/ms971323.aspx#atg_keyboardshortcuts_complying_with_standard_keyboard_navigation
Thank you!
Andrei
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
