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.


–¬†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: https://github.com/andreituicu/MuseScore

Full proposal: https://www.dropbox.com/s/c4ndm842u201j9w/AndreiTuicu_Proposal_MuseScore.pdf