Ok, let’s see what I did this week. 🙂
Beside of what I presented in the post from yesterday I also made the status bar work properly for the next type of elements:
– Time signature
– Repeat Measures
I also implemented a system that tells the ScoreAccessibility class that the the current information has changed. For those of you who don’t want to read the long version in the previous post, here is the short one. 🙂
Bassically is an Observer pattern implemented with signals and slots. So the ScoreAccessibilityInfo has a slot that updates the status bar and the ElementAccessibilityInfo and Element each have a signal for telling the the information has changed. The signal from Element is connected to the signal from ElementAccessibilityInfo which in the end is connected to the slot from ScoreAccessibilityInfo for the object the ocupies the status bar. The reason why I like very much the signal/slot system in combination with the Observer pattern is that you don’t have to check if there is something else connected to the other end. You just emit the signal and if there is a ElementAccessibilityInfo instantiated, it will propagate the signal and if it’s also connected to the slot, it updates the status bar, but like I said there is no checking required. I think that this is a very nice way of applying the “Tell, don’t ask” principle.
Also, I got in touch with one of the main developers for Accessibility from Qt, Frederik Gladhorn, and he was able to help me with most of the problems that I had. Now the code works in my testing project so I can start moving it in MuseScore. I wasn’t yet able to give “fake” focus to a QObject so that the screen-reader can view it, but once I do that I will unpload the project so that anyone can use it. There are two things that I would like to mention here, that are not specifically written in the Qt documentation:
– Most screen-readers ignore any update that is not about the widget that has focus
– Child(0) is not the object itself, it’s the first(if it exists) child widget
This week I’ll probably have working the screen-reader and the basic information collected about all the Element objects so I can start collecting extra info.
As I discussed with Marc, the status bar will only have the basic information, but the screen-reader will actually tell more, like for example for a note: what annotations, articulations it has, if it has explicit accidentals, etc. We will provide all this info, but the user doesn’t need to listen to it every time, since moving to the next element makes the screen-reader tell the info of that one.
Thank you for reading!
See you next week! 🙂