Re: [Mscore-developer] Keyboard usability and accessibility
On 06/09/2014 11:33 AM, Andrei Tuicu wrote: > From the knowledge that I have so far, I don't know any way in which I > can say something like "start from here" for the tabbing order, at > least not provided out of the box by Qt. OK. If so, that means if the Inspector gains focus on simply click of a button (like the arrows on a Spin box), then pressing Tab afterwards will move control to the toolbar rather than the next control within Inspector. But I assume you actually click *within* a spinbox, so you are now in text, Tab will still take you to the next control within the Inspector. This is fine by me. And as I've mentioned, I actually think it would be fine if focus were completely moved to Inspector any time you click in it (see below), but playing with it for real will let me say for sure. Which is to say, I don't think there is any need to worry about the "start from here" idea. > >then clicking an Inspector button won't transfer focus there. That's > fine. But what if the very next thing I do is press Tab? Your > current proposal would >presumably to exactly what would have happened > if I had not pressed an Inspector button first - focus will move to > the first toolbar button. That's because >at the moment the user > presses Tab, the focus is still in the score subwindow. > > Yes, you are right, this is what is happening at the moment, but this > happens not because the score has focus, but because tabbing order is > actually the list of objects from the window, in the order in which > they are created. Yes, but if focus were actually in the Inspector rather than the score tab, I assume pressing Tab would simply move to the next control in the Inspector rather than moving to the toolbar. That's what I'm discussing above. If clicking anywhere in Inspector actually transferred focus, then pressing Tab next would presumably move to the next control within the Inspector, which I believe is what Miwarre was saying he wanted. I realize a lot of this seems pretty nit picky. Realistically, for most of us (sighted) users, none of this will matter. But it is definitely the sort of thing that can make a big difference to a blind user. Marc -- 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://p.sf.net/sfu/hpccsystems ___ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
Re: [Mscore-developer] Keyboard usability and accessibility
I've created this GoogleDoc[0] were I've assigned every action defined in
actions.cpp to its window. I don't know what every action does, so I would
really appreciate if some of you could please take a quick look at it. In
the column named Observations I've put question marks where I'm not certain
that I've corectly assigned the shortcut to its widget.
I only moved actions from the main window to the scoretab and for them I've
set the context to WidgetWithChildren. I see that there are actions that
have effect in to whole application (they have the context Application
shortcut) I've kept those in the main window.
I've granted access to everyone for editing so you can make changes
directly into that document.
Thank you very much!
Andrei
[0]
https://docs.google.com/spreadsheets/d/1RbOLweFvoXxSYrJ-BMFmUiL1_b0lgzJvlDjPbbRcCew/edit?usp=sharing
2014-06-09 20:33 GMT+03:00 Andrei Tuicu :
> 2014-06-09 19:43 GMT+03:00 Marc Sabatella :
>
>
>> On 06/09/2014 10:03 AM, Andrei Tuicu wrote:
>>
>> 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.
>>
>>
>> True, but it's not clear any of had completely thought through the
>> different possibilities at the time of that discussion - how the Inspector
>> might different form the toolbars in this respect. This could well be
>> something you have to implement and play with (or let others play with) to
>> really get a sense of.
>>
>
> Well the implementation will be ready these days (I'm hoping by tommorow),
> so you and others can try it and give me feedback after playing with it.
> The only thing that I have to do now is assign to every action its window
> and that is the only thing that takes a bit of time, because I have to do
> this in actions.cpp for every action.
>
>>
>>
>> >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
>>
>>
>> I think it is my turn to not have explained myself clearly :-). I think
>> I am talking about something different here.
>>
>> I am talking about what happens if I first click a button in Inspector,
>> and then press Tab. If you set Inspector's elements to TabFocus, then
>> clicking an Inspector button won't transfer focus there. That's fine. But
>> what if the very next thing I do is press Tab? Your current proposal would
>> presumably to exactly what would have happened if I had not pressed an
>> Inspector button first - focus will move to the first toolbar button.
>> That's because at the moment the user presses Tab, the focus is still in
>> the score subwindow. What I am suggesting is that the code for Tab could
>> perhaps, if possible, check to see if the user had "recently" pressed a
>> button (we'll call it "X"), and if so, move focus to the next button in the
>> tab order ("Y"), *even though focus is not actually on button X but was
>> actually in the score subwindow). In other words, if there is a concept of
>> an "active" button, have the Tab key start focus with the next button after
>> the active button, rather than the first toolbar.
>>
>> *In addition* to this, yes, it would nice to have Ctrl+Tab or some other
>> command move to the next subwindow *once you've already moved focus to a
>> toolbar or subwindow*. But I'm not talking about what happens after you
>> transfer focus to the subwindow; I'm talking about what the very first
>> press of Tab actually does.
>>
>> BTW, regarding the "in addition" comment - I don't actually to *limit*
>> tab to only working within the current subwindow. In other words, the
>> default behavior of Qt is fine - when you reach the end of one subwindow,
>> move on to the next. That's fine, I think. I just want a *quicker* way to
>> move to the next subwindow without having to first go through everything in
>> the current one.
>>
>>
>> The Windows guidelines for Keyboard UI navigation[0] say the following:
>>
Re: [Mscore-developer] Keyboard usability and accessibility
2014-06-09 19:43 GMT+03:00 Marc Sabatella :
>
> On 06/09/2014 10:03 AM, Andrei Tuicu wrote:
>
> 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.
>
>
> True, but it's not clear any of had completely thought through the
> different possibilities at the time of that discussion - how the Inspector
> might different form the toolbars in this respect. This could well be
> something you have to implement and play with (or let others play with) to
> really get a sense of.
>
Well the implementation will be ready these days (I'm hoping by tommorow),
so you and others can try it and give me feedback after playing with it.
The only thing that I have to do now is assign to every action its window
and that is the only thing that takes a bit of time, because I have to do
this in actions.cpp for every action.
>
>
> >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
>
>
> I think it is my turn to not have explained myself clearly :-). I think I
> am talking about something different here.
>
> I am talking about what happens if I first click a button in Inspector,
> and then press Tab. If you set Inspector's elements to TabFocus, then
> clicking an Inspector button won't transfer focus there. That's fine. But
> what if the very next thing I do is press Tab? Your current proposal would
> presumably to exactly what would have happened if I had not pressed an
> Inspector button first - focus will move to the first toolbar button.
> That's because at the moment the user presses Tab, the focus is still in
> the score subwindow. What I am suggesting is that the code for Tab could
> perhaps, if possible, check to see if the user had "recently" pressed a
> button (we'll call it "X"), and if so, move focus to the next button in the
> tab order ("Y"), *even though focus is not actually on button X but was
> actually in the score subwindow). In other words, if there is a concept of
> an "active" button, have the Tab key start focus with the next button after
> the active button, rather than the first toolbar.
>
> *In addition* to this, yes, it would nice to have Ctrl+Tab or some other
> command move to the next subwindow *once you've already moved focus to a
> toolbar or subwindow*. But I'm not talking about what happens after you
> transfer focus to the subwindow; I'm talking about what the very first
> press of Tab actually does.
>
> BTW, regarding the "in addition" comment - I don't actually to *limit* tab
> to only working within the current subwindow. In other words, the default
> behavior of Qt is fine - when you reach the end of one subwindow, move on
> to the next. That's fine, I think. I just want a *quicker* way to move to
> the next subwindow without having to first go through everything in the
> current one.
>
>
> 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.
>
>
> Ah, thanks for the reference. I thought as much regarding Ctrl+Tab, but
> that was based more on gut feel & memory of experience than on actually
> knowing a specific guideline.
>
>
> Since CTRL+TAB is used for changing from one tab of score to another,
> CTRL+F6 is the next best thing.
>
>
> As far as I am concerned, Ctrl+Tab should be no different than other
> shortcuts here. *If focus is currently in a score tab*, then indeed,
> Ctrl+Tab would move to the other. But *if focus is in the toolbar*, then
> Ctrl+Tab should move to the Inspector. I guess this is a bit inconsiste
Re: [Mscore-developer] Keyboard usability and accessibility
On 06/09/2014 10:03 AM, Andrei Tuicu wrote:
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.
True, but it's not clear any of had completely thought through the
different possibilities at the time of that discussion - how the
Inspector might different form the toolbars in this respect. This could
well be something you have to implement and play with (or let others
play with) to really get a sense of.
>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
I think it is my turn to not have explained myself clearly :-). I think
I am talking about something different here.
I am talking about what happens if I first click a button in Inspector,
and then press Tab. If you set Inspector's elements to TabFocus, then
clicking an Inspector button won't transfer focus there. That's fine.
But what if the very next thing I do is press Tab? Your current
proposal would presumably to exactly what would have happened if I had
not pressed an Inspector button first - focus will move to the first
toolbar button. That's because at the moment the user presses Tab, the
focus is still in the score subwindow. What I am suggesting is that the
code for Tab could perhaps, if possible, check to see if the user had
"recently" pressed a button (we'll call it "X"), and if so, move focus
to the next button in the tab order ("Y"), *even though focus is not
actually on button X but was actually in the score subwindow). In other
words, if there is a concept of an "active" button, have the Tab key
start focus with the next button after the active button, rather than
the first toolbar.
*In addition* to this, yes, it would nice to have Ctrl+Tab or some other
command move to the next subwindow *once you've already moved focus to a
toolbar or subwindow*. But I'm not talking about what happens after you
transfer focus to the subwindow; I'm talking about what the very first
press of Tab actually does.
BTW, regarding the "in addition" comment - I don't actually to *limit*
tab to only working within the current subwindow. In other words, the
default behavior of Qt is fine - when you reach the end of one
subwindow, move on to the next. That's fine, I think. I just want a
*quicker* way to move to the next subwindow without having to first go
through everything in the current one.
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.
Ah, thanks for the reference. I thought as much regarding Ctrl+Tab, but
that was based more on gut feel & memory of experience than on actually
knowing a specific guideline.
Since CTRL+TAB is used for changing from one tab of score to another,
CTRL+F6 is the next best thing.
As far as I am concerned, Ctrl+Tab should be no different than other
shortcuts here. *If focus is currently in a score tab*, then indeed,
Ctrl+Tab would move to the other. But *if focus is in the toolbar*,
then Ctrl+Tab should move to the Inspector. I guess this is a bit
inconsistent in that it suggests Ctrl+tab should also take you out of
the second score tab and onto the toolbar, and I guess that could be OK
too. In other words, Ctrl+Tab could cycle between ScoreTab1, ScoreTab2,
Toolbar, Inspector, MuseScore Connect, Palette (eventually) and then
back to ScoreTab1. With Shift+Ctrl+Tab moving backwards through that
same cycle. But if the guidelines don't forbid it, I think I'd rather
have two difference cycles. If you start in a score tab, then Ctrl+Tab
ju
Re: [Mscore-developer] Keyboard usability and accessibility
@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
Re: [Mscore-developer] Keyboard usability and accessibility
One other general comment: it's all well and good for us to theorize about how it might seem if you made certain UI changes, but in my experience, it's often just as easy and almost always more useful to actually implement it and play with it to get a "feel" for how well it works. I find this is especially true when it comes to keyboard interactions. Marc -- 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
Re: [Mscore-developer] Keyboard usability and accessibility
On 06/08/2014 09:57 AM, Andrei Tuicu wrote: > 3. (optional) Restrict the user from assigning keys like Return, Tab, > Arrow keys as shortcuts. I'm personally OK with this restriction. At least, I can't think of a reason to care. Would this also extend to Ctrl+Arrow, Shift+Alt+Arrow, etc? I suspect the accessibility work will end up adding a number of new commands that will need shortcuts like this, and blind users might want to reassign those to be easier. Marc -- 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
Re: [Mscore-developer] Keyboard usability and accessibility
On 06/09/2014 05:54 AM, Maurizio M. Gavioli wrote: > AndreiTuicu wrote >> If for example I select a button using TAB and press Return, the button >> will not be clicked, instead the system break action will be triggered. If >> I'm editing text in a textbox and press CTRL+A I'm not selecting the whole >> text, instead I'm triggering the action that selects all the elements from >> the score. > I'm using Linux, but I cannot confirm this: > > *Arrows*: I can move around in menus with the arrows, without them affecting > the score. Menus and dialogs work fine indeed. The issue as described only affects controls within subwindows of the main window - eg, spin boxes in Inspector, as you observed later. This is the same on Linux as on Windows. > . And for dialogs, it's already the case that these are separate > windows*TAB/Shift-TAB*: I can move from one dlg control to the other with TAB > and > Shift-TAB, without affecting the score (both in modal dlgs, like, for Here, he was talking specifically about the toolbar, not dialogs or subwindows. Currently, there is no way to transfer keyboard control to the toolbar in the first place, but that is one of of the changes he made earlier in his code (not yet merged): Tab transfers control from the score to the toolbar, an important requirement for accessibility. > *Ctrl-A*: I can select whole text in dlg text controls and even in score > textual elements (in edit mode) with Ctrl-A without it selecting the whole > score. Here again, the issue is with subwindows only. Try clicking in the Search window in MuseScore Connect, typing some text, then selecting it via Ctrl+A. > 1. Move every QAction that affects the score in the ScoreTab object and > change their shorcutcontext from WindowShortcut to , leaving in the > MuseScore object (Main window) just those that open subwindows, > dialogs,etc. > > 2. Set the focus policy for all the other subwindows of the main window so > that the they don't receive focus by clicking on their elements (except > for the case when text editing is necesary) > > 3. (optional) Restrict the user from assigning keys like Return, Tab, > Arrow keys as shortcuts. > I have no clear idea of the consequences of 1), but I assume you have > studied the matter. > > 2) raises some questions. I believe 2) is necessary to address the consequences of 1) :-). The idea of 1) is that each subwindow - including the score tabs - will "own" its shortcuts, meaning shortcuts are active only while focus is in that window. By default, this might mean that pressing one of the note duration icons would transfer focus to the toolbar, so you'd need to click back in the score to actually enter notes. 2) would be needed to keep focus in score even when pressing toolbar buttons, etc. 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? 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. Marc -- 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
Re: [Mscore-developer] Keyboard usability and accessibility
AndreiTuicu wrote > If for example I select a button using TAB and press Return, the button > will not be clicked, instead the system break action will be triggered. If > I'm editing text in a textbox and press CTRL+A I'm not selecting the whole > text, instead I'm triggering the action that selects all the elements from > the score. I'm using Linux, but I cannot confirm this: *Arrows*: I can move around in menus with the arrows, without them affecting the score. *TAB/Shift-TAB*: I can move from one dlg control to the other with TAB and Shift-TAB, without affecting the score (both in modal dlgs, like, for instance "File | Info" and non-modal dlgs like Inspector). *Ctrl-A*: I can select whole text in dlg text controls and even in score textual elements (in edit mode) with Ctrl-A without it selecting the whole score. There is one glitch, though: in the Inspector, numeric fields are assumed to be 'spinnable' with arrows, but using arrows, for instance with a note selected, changes the pitch of the note rather than the spin value. Possibly, something to tune in the dlg design? For the rest, I am noting no mis-behaving of key strokes associated with shortcuts. > 1. Move every QAction that affects the score in the ScoreTab object and > change their shorcutcontext from WindowShortcut to , leaving in the > MuseScore object (Main window) just those that open subwindows, > dialogs,etc. > > 2. Set the focus policy for all the other subwindows of the main window so > that the they don't receive focus by clicking on their elements (except > for the case when text editing is necesary) > > 3. (optional) Restrict the user from assigning keys like Return, Tab, > Arrow keys as shortcuts. I have no clear idea of the consequences of 1), but I assume you have studied the matter. 2) raises some questions. On one hand, the fact that the Inspector, the Palette and, say, the zoom control keep the focus once open or clicked and do not release it until the user does not clicks on the score window is rather inconvenient (for instance, pressing F8 opens the Inspector, but pressing F8 again does NOT close it). On the other hand, having the Inspector retaining the focus ensures that it can be navigated via the usual keystrokes, without re-clicking on it. > Details [snipped]: > > I would like your opinions regarding the following: > Q1: What do you think about step 3? > Q2: Do you know other usecases in which the scoretab should give away the > focus, except when editing text? Q1 - Step 3: Except for the 'spinnable' Inspector values, I am not experiencing any issue with shortcuts using keys also used to navigate dlgs and menus. I don't know if it a Linux-only privilege, but this point seems to me fine as it is. Q2 - window focus: see my doubts above. Would it not rather be the case to have a 'system'-key which would move the focus to the main score window from wherever it is? Once upon the time, F10 used to do something similar in many (Windows?) apps (from the main app window to menus and back). Hoping this can be of some usefulness, Maurizio -- View this message in context: http://dev-list.musescore.org/Keyboard-usability-and-accessibility-tp7578844p7578845.html Sent from the MuseScore Developer mailing list archive at Nabble.com. -- 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
[Mscore-developer] Keyboard usability and accessibility
Hello, everyone! In order to make add accessibility and make everything work as expected I think that the whole mechanism of shorcuts and actions should be restructured a bit. In my opinion these are the main problems of the current implementation: - all the shortcuts are global - (optional) the user can set assign any shortcut to an action without any restrictions So this is what happens: If for example I select a button using TAB and press Return, the button will not be clicked, instead the system break action will be triggered. If I'm editing text in a textbox and press CTRL+A I'm not selecting the whole text, instead I'm triggering the action that selects all the elements from the score. After talking to Marc and Lasconic I propose the following solution: 1. Move every QAction that affects the score in the ScoreTab object and change their shorcutcontext from WindowShortcut to , leaving in the MuseScore object (Main window) just those that open subwindows, dialogs,etc. 2. Set the focus policy for all the other subwindows of the main window so that the they don't receive focus by clicking on their elements (except for the case when text editing is necesary) 3. (optional) Restrict the user from assigning keys like Return, Tab, Arrow keys as shortcuts. Details: For 1. I will create a global enum that will specify for what window/object is the QAction intended. In this way, if in the future other actions will be added that are supposed to go in other objects, the only thing that will be needed is to add a new value for that enum. Since every action is instantiated in the action.cpp file using a Shortcut object, I will put a variable of that enum type as field in the Shortcut object. For 2. : Since all actions are in the main window at the moment and their shortcut context is WindowShortcut, the focus *appears* to be always in the scoretab. In order to preserve this behavior where this is desired and avoid the bad examples I've given above I need to set the focus policy for all the other objects so that they don't give away the focus to other elements. It would be nice to set a property for scoretab so that it doesn't give away the focus, but this is not possible. The only usecase I see when the focus should leave the scoretab is when editing text in another subwindow. For 3: This step is debatable. With the default shortcuts assigned in the way they are now, everything will work as desired, but this doesn't mean that a user cannot reassign keys like: Return, Tab, Arrow keys as shortcuts for other actions and create problems. This is a question if we consider that is MuseScore's responsability to restrict the user from poorly assigning shortcuts, or it is the user's responsability. In the first case, the above mentioned keys will be handled like KeyPressEvents in the scoretab object and their behavior for the scoretab will be hardcoded. I would like your opinions regarding the following: Q1: What do you think about step 3? Q2: Do you know other usecases in which the scoretab should give away the focus, except when editing text? Beside my two questions I would very much appereciate any comments regarding my suggestion, or if you have other questions they are all wellcome. :) I've implemented a part of this solution and I've done some tests and all seems to be working as expected. Thank you very much! Andrei -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
