All posts by andreituicu

weeks[1].toString(); //Tool Bar and Dialogs

Hello everyone!

Before the weekly update, I would like to thank Jaffar Ahmad Sidek for all his help. Jaffar is a blind musician and programmer who is helping me and Marc Sabatella when we are not sure about the details of how an aspect of accessibility should be addressed. By consulting with him we make sure that when this project is finished, MuseScore’s support for accessibility will be what visual impaired musicians expect. Thank you, Jaffar! 🙂

Let’s start with the progress update:

1. Tool Bar

1.1 What I’ve done:

– In the last post I’ve said that there are 5 more objects in the tabbing order that should not be there, now there is only one and with help from Marc, we narrowed down the search place to the Palettes.

– I have fixed the problem of Return key being a global shortcut for the system break command. Remainder: This meant that other objects would not receive any event if the Return key was being pressed. 

Here the problem was a bit more complicated, as David Bolton pointed out some programs choose to create a whole new state for tabbing throught the toolbar when the ALT key is pressed and we weren’t sure if it was a good idea to create a new state for MuseScore. Also the Space key is used for clicking buttons in other programs and in MuseScore it is set as shortcut for score playback.  I’ve asked Jaffar about this issues and here are his answers:

Q: It is expected for the ALT key to be pressed before starting the tabbing?
a: No it is not necessary.
Q: Should tabbing start from the first menu and continue to the tool bar, or it is better like I did it to keep the Tool bar and the menu bar separated?
a: I guess this is a sort of in between answer.  Most modern apps have their menus and tool bars in sync, but older apps have their menu and tool bars separately.  but I think most blind users would prefer to have menus and tool bars separate.
Q: Is it ok if we keep the Space key mapped for Play/Pause score playback? I saw that this is how other programs do it too.
A: Please do.  You are right. most music related apps have the space bar as the play/pause button so most blind users would find it comfortable.
Taking his advice, I’ve kept the the tool bar and the menu bar separeted and the Space key mapped as shorcut for score playback. When it comes to the Return key problem, I’ve removed it as a shortcut and now it is treated as a Key Press Event in the scoretab object. The only object who receives a Key Press Event from Qt (by default) is the object that has focus. Now, when a toolbar button has focus and the Return key is pressed, the button will be clicked(his action will be triggered), when the scoretab has focus the system break action is triggered, later if a palette option has focus it will be applied to the score, etc.
You can see the commit here [0] .
1.2 Problems
-The only problem that I’ve encountered here was with Qt. I needed a pointer to the main window (the parent of the scoretab object) so that I could check its state and see if matches the states when the system-break action should be triggered. Even if the constructor of the scoretab was passing the parent pointer to QWidget ( ScoreTab(QList<Score*>* sl, QWidget* parent) : QWidget(parent)  ) and when calling it from the main window like this: new ScoreTab(&scoreList, this); , later on when asking for the parent pointer ( this->parent() ), the result was not what I would’ve expect.I was unable to see the changes made to the main window (like state change) from the pointer. The solution was to create my own pointer in the ScoreTab class and then everything worked perfectly.
1.3 What else needs to be done:
– Make the buttons be highlighted when Shift+Tab is pressed ( reverse tabbing)
– After talking to Marc, we’ve concluded that there should be a way to move from subwindow to subwindow (workspace, palettes, toolbar, inspector, etc), using a key sequence and the elements included in the tabbing order should be only those from the current selected subwindow. This is provided out of the box from Qt if the subwindow is undocked, but if not, all it’s objects are included in the tabbing order. Also, the solution for this should be something maintanable, something that should not be changed for every element, button, or new window that will be added to MuseScore in the future.
2. Dialogs
2.1 What I’ve done
– I began with the New Score dialog, I’ve set the tabbing order and the screen-reader feedback for the first part of it, but when I’ve moved to the other parts, I’ve noticed that there are dependencies with the clef palette and the instruments dialog and I’ve decided to take more time to carefully read the code before making any changes there.
– In the mean time I’ve set the tabbing order for the whole prefferences dialog and I’ve added the screen-reader feedback for the first tab of the dialog (general).
2.2 Problems
The following are problems from Qt:
– The screen-reader tells the text from all the QLabels when the dialog is openend
– Even if the tabbing order is set, you cannot go from button to button in a group if it is set as exclusive. You can only enter the group and move from one button to another using the arrow keys. I have to look more into accessibility guidelines and see how should I address this issue.
2.3 What else needs to be done:
– Finnish adding screen-reader support for prefferences dialog
– Finnish setting the tab order and adding screen-reader support for new score dialog
Other things worth mentioning:
I’ve looked more into the behavior of the ALT key. When this key is pressed, the first menu should be selected (in MuseScore’s case File menu). This is implemented as default behavior by Qt, so if I create a new application with a menu bar, I get the expected behavior. For some reason this doesn’t happen in MuseScore. Somewhere this behavior is overriden, but I wasn’t able yet to figure out where.
Marc Sabatella has approved the changes that I’ve made so far, so I’ve started working on the first “how to” blog post and I will post it during this week.
Thank you for taking the time to read this! 🙂

weeks[0].toString(); //Menus and Tool Bar


This is my first weekly post regarding the progress of the Accessibility support project* that I’m working on at MuseScore. I’ve started a bit earlier with my work in order not to fall behind in the final exams period.  Ok, lets get started. 🙂

 1. The first thing that I addressed is the menus issue:

1.1 What was already working:

(usually, in this sections you will find the things that are provided out of the box by Qt 5.2)

– Menus can be opened using shortcuts

– The next menu and previous menu can be accessed using the left and right arrow keys

– The screen-reader tells the menu’s name

– Menu options can be accessed using up and down arrow keys

– The screen-reader tells the option’s name


1.2 What I’ve done:

– I’ve successfully made the screen-reader tell menu’s default shortcut along with it’s name. (see commit here [0])

1.3 Problems:

– The only major problem that I had here was trying to make the screen-reader tell the menu option’s shortcuts (if they are set) along with it’s name.  After wasting some days setting every property and every attribute that I could see, in every possible combination, for both QAction and QMenu objects I’ve concluded that this is not possible and I’ve submitted a bug report at Qt project. The developer from Qt project confirmed not only that this is a bug, but also told me that Qt should provide the shortcut out of the box. You can find the bug report here[1] and also two threads that I’ve created on Qt dedicated forums here[2][3].

1.4 What else needs to be done:

Strictly speaking  about menus, I think that the only thing left to be done is set the focus on the first menu when ALT key is pressed.

2. After menus, I’ve moved on to the tool bar:

2.1 What was already working:

– The screen-reader was telling for every button his name, a short description of it’s purpose and (if set) its shortcut.

2.2 What I’ve done:

– I’ve created a class that extends the QToolButton in order to provide accessibility for tabbing

– I’ve added to the tabbing order all the buttons that open dialogs with native support for accessibility

– I’ve removed almost all (5 more remaining) objects that are not relevant from an accessibility point of view

– I’ve made it so buttons are highlighted when they gain focus by tabbing

– I’ve made it so that buttons are “pressed” when the Return/Enter key is pressed (see also the 2.3 section for problems)

(Commits here[5])

2.3 Problems:

– A small problem was that I couldn’t highlight the button like when the movese hovers over it (if anyone know how can I do that, please leave a comment here, thank you!)

– Another problem, for which I’ve created also a bug report[4] was that both Space and Return keys were already assigned as shortcuts, so even though the button would react as expected when the Return key is pressed, the object is not notified when this event occurs, because shortcuts have priority.


Other things worth mentioning:

This last problem that I’ve mentioned is not as simple as it sounds. Beside having multiple ways in which it can be solved, some of them involve creating a whole new global state for the program and it is not yet clear if this is a good idea when looking at the big picture.

One more thing. I’ve noticed that the accessibility part of Qt is not very well documented and has very few (or none) code examples, so it involves a lot of trying and failing until the desired behavior is achieved. That beeing said, I will try to write here general “how to”s, with code examples so that others, who are trying to do the same thing, won’t need to take the whole “searching, trying, failing” process from the begining.

That’s all for this week. 🙂


*for more details, please read my first post

Hello world!

Hello everyone! My name is Andrei Tuicu and I’ve been selected to work at MuseScore for Google Summer of Code 2014. My project is called Accessibility with Focus on Visually Impaired Musicians and I will work with Marc Sabatella’s guidance and with the help of Jaffar Ahmad Sidek. On this blog I will be posting weekly updates regarding the progress of my project. At the bottom of this post you will find a link to my fork of MuseScore’s repository on GitHub and a link to the full proposal that I’ve submited for GSOC in PDF format.

Now lets talk a bit about the project.

What is accessibility?

Accessibility means making sure that an application/a web page can be accessed by individuals with disabilities using specific assitive technologies.

What are assistive technologies?

Assistive tehnologies are tools on which people with disabilities rely on in order to use the computer. This tools can be either hardware like Braille-displays, head pointers or software like screen readers. For my project I will focus on adding support for screen-readers and if time allows it Braille-displays in MuseScore.

A screen-reader is a program that bassically tells the content of the screen to the user, allowing him to hear rather then read what is displayed. A Braille-displayis an electro-mechanical device for displaying braille characters, usually by means of round-tipped pins raised through holes in a flat surface. 

Why this project?

When we talk about music score editors, one of the most notable aspects is the fact that very few of them are designed with accessibility in mind, or scarcely do they provide support for it. If they indeed meet this need, most of them are quite expensive. This leaves blind or visually impaired musicians who wish to create scores in standard notation with very few options. Another important aspect is that not only those who want to create scores have difficulties in doing that, those who just want to read scores and learn to play an instrument have the same problem. In truth, there are very few scores printed in Braille or available in other accessible formats online. Also, at this point there is a gap between blind and sighted musicians. Blind musicians are interested in writing in the standard notation so that sighted musicians can play their music, as well as to be able to play the scores written in standard notation. At the end of the project MuseScore will break the barriers between the two categories of musicians by providing a common ground.

GitHub repository:

Full proposal: