On 5/6/2014 11:42 AM, Andrei Tuicu wrote: > I've started working on menus. For now I've succesfully made the > screen-reader tell both the name of the menu and it's keyboard > shortcut, you can see the commit here[0]. However I wasn't able to do > the same thing with the menu options. Even though the shorcut is > listed, the screen reader cannot see it. Menu options are created > using the QAction class and I've tried setting all of it's properties, > but the only one that the screen reader can access is the text > property, which contains only the name of the option. Next I want to > try using the QAccessibleInterface and if that dosen't work, the only > solution that I can think of is to add all of the menu's options and > shortcuts to the menu's description.
Have you looked into how other Qt applications do this? As we've discovered, VLC uses Qt and the menu shortcuts *are* read. Here's the source for menus.cpp in VLC: https://github.com/videolan/vlc/blob/master/modules/gui/qt4/menus.cpp I looked over it trying to see if there was anything special going on, but I don't see it. It seems it doesn't first create the action then add it as we do; it creates the actions on the fly using one of the longer forms of addAction. I guess it's possible that is significant. The other thing that jumped out at me as being different is that we always add a *list* of shortcuts with setShortcuts rather than setting a single primary one with setShortcut. I did try changing our shortcut.cpp to call setShortcut with the first shortcut only, but that didn't change anything. I didn't have your changes as a starting point though; maybe that would help. Anyhow, it certainly appears this should be possible withut resorting to adding all menu options to the main menu description, so maybe looking more closely at VLC will give us the answer. I believe Jaffar is now on this list, so maybe he will have other ideas. > After finishing with the menus I was planning on working on the > tabbing for the main window and the screen reader feedback provided > for it, but if think it is more important I can start with dialogs, > like the "Create New Score" dialog. So please let me know your opinion. I don't have a strong feeling here. The main window is bad as far as tab is concerned; I can't tell what it's doing at all. But really, very little on the main window is inherently accessible right now even if Tab could get you there. It might make sense for now to just simplify the tab order to just move between the score tabs and the transport (playback) toolbar and skip the note entry toolbar, palettes, inspector, etc. Regarding dialogs, lots of them will need work. But again, given that nothing about creating scores is accessible right now, there is no reason to worry a whole lot about the Create New Score wizard right now. I'd focus first on whatever dialogs are necessary to allow a user to load one or more scores, switch between them, play them, generate parts, print, save as, save online, etc. That is, nothing to do with editing scores, but working with them more generally. Marc ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
