weeks[3].toString(); //Actions, shortcuts and dialogs

I would like to start this post by saying that I’ve finished my finals. Starting from now, I’m going to dedicate my full time to this project. 🙂

This week I’ve worked on the following issues:

1. Actions and shorcuts

1.1 What I’ve done

I’ve implemented the solution that I’ve talked about in the previous post.

Here is the discussion from the mailing list[0]. You will find there more details then in my previous blog post.


There were three steps in this solution

I.  Move every QAction that affects the score in the ScoreTab object and change their shorcutcontext from WindowShortcut to WidgetWithChildrenShortcut, leaving in the MuseScore object (Main window) just those that open subwindows, dialogs,etc.
II.  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)
III. (optional) Restrict the user from assigning keys like Return, Tab, Arrow keys as shortcuts.

After talking to Marc, I’ve only created a restriction for the Tab key, because there was not way for a blind user to move around the shortcut capture dialog. Before, if the Tab key was pressed it was seen as a shorcut assignement and it was not ok, since it is crucial for blind users to be able to configure their preffered shorctus.

1.2 Problems

The only problem here was knowing which action should go where. There wasn’t an exact criteria for this.

You can find a google doc with the shorcut asiggnmets here[1]:


And with this solution I’ve created my first pull request for the accessible-toolbar. 🙂


2. Dialogs

2.1 What I’ve done

I’ve finished adding the screen-reader feedback for all the elements of the prefferences dialog and also for the shorcut capture dialog.

2.2 Problems

I didn’t have big problems, but there are some glitches.

– One of the things is that the screen-reader doesn’t tell the new values of the combo boxes when they are changed

– The second one is a two way street. On one hand I don’t like that in dialogs like Preferences the screen-reader reads the QLabels, but on the other hand it is importand that it reads them in small dialog windows, like shortcut capture dialog, or warning/error dialogs

2.3 What else needs to be done

Here the next will be to start working on the Inspector.

[0] http://dev-list.musescore.org/Keyboard-usability-and-accessibility-tt7578844.html

[1] https://docs.google.com/spreadsheets/d/1RbOLweFvoXxSYrJ-BMFmUiL1_b0lgzJvlDjPbbRcCew/edit?usp=sharing


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s