weeks[4].toString(); // More Dialogs and Navigation

It’s time for a new weekly blogpost! 🙂

This week I’ve continued working on dialogs and I started implementing new navigation commands.

1. Dialogs

1.1 What I’ve done

As usual I’ve made sure that the focus policies and the tabbing order are correct and also that the appropriate screen-reader is provided for the next dialogs/wizards:

– Inspector (all UIs)

– Instrurment Wizard

– New Wizard

– Time Signature wizard

– Create new score dialog

1.2 Problems

–  I fixed two minor bugs in the shorcut capture dialog: Clear button was a QToolButton instead of a QPushButton, so when pressing Enter, the Add button was pressed, also pressing Clear button did not disable the Add and Replace buttons.

– I’ve found a Qt bug regarding the QTreeWidget object. When pressing Enter the QTreeWidget object handles the key press event, but doesn’t stop it, so the event goes to the next object. This is why, if you select an instrument in the Create new score dialog and press Enter, the instrument is added, but also the Next button is pressed. The same thing happens in the Prefferences dialog with shotcuts, if you press Enter the shorcut capture dialog is opened, but when it’s closed, the Ok button is pressed as well and the Prefferences dialog closes too.

– I also have some problems with the screen-reader feedback for the added instruments

1.3 What else needs to be done

– Fix the last two problems mentioned

– Since the key signature is added using the palettes, that part will work once I start working at them

– Other dialogs

– Now that the focus policy for every individual element of the Inspector has been set, I’m waiting for the branch with the action restructuring to be merged into the main repository, so that I can rebase this branch on top of those changes and add the Inspector to the tabbing order


2. Navigation

The goal here is to create some commands that will enable blind users to traverse all the score elements. This week I familiarized with how the score is stored.

2.1 What I’ve done

I’ve almost finished writing a command that will enable blind users to “read” the score. This command traverses staff by staff all the main (non attached) elements: clefs, key signatures, notes (from top to buttom in a chord), rests, barlines, breaths. This command will work great in combination with the screen-reader feedback that I will implement later, since the screen-reader will have to tell not only the main elements, but also the attached elements. For example, if I have a C note, with a # accidental, I don’t want to have to traverse the C note, and after that the accidental, to find out the pitch. I want to traverse the note and the screen-reader should tell me C#. Of course, I will implement another command to traverse this element’s attached elements, since users don’t need just to know that they are there, they have to be able to select them and edit them, without using the mouse.

2.2 Problems

– The implemented command works well when the selected element is one of those enumerated above, the problem appears when the selected element is not of them. To solve this I need to find a way to get to the parent segment of every element, prefferably with as few ifs as possible.

2.3 What else needs to be done

– Now, the command, only traverses one staff and I need to implement something to make it go to the next staff as well

– Implement the command for traversing the attached elements


That’s all for this week! 🙂




One thought on “weeks[4].toString(); // More Dialogs and Navigation”

  1. Great work!

    Regarding the tree / Enter issue, I’m not so sure it’s a bug that the event is passed along. At least, as I mentioned, MuseScore uses this to good effect right now, letting you add an instrument and move on to the next screen of the wizard in one step – to me, that’s a feature :-). But maybe there needs to be some control over this behavior?

    Regarding the need to get the segment of any element – in theory (my opinion, anyhow), each element should have a segment() method already. In practice, they don’t. There has been talk of implementing a tick() method for all elements (in conjunction with work being done by bartlomiej_lewan), that basically amounts to the same thing. If you really need this, maybe we should work to make that happen.

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