On 5/15/2014 4:21 PM, Andrei Tuicu wrote: > First of all, after a week of trying to set every property and > attribute for a QAction, contained in a QMenu, in every possible > combination and reading everything about menus in VLC, I've finally > decided to ask about shortcut issue on Qt's forums. You can find the > disscusion threads here[0][1]. I've found out that is actually a bug > from qt and the developer that is assigned for accessbility confirmed it.
OK, thanks for being so thorough! My feeling is that you shouldn't spending your time fixing their bugs unless we get the sense they have no intention of fixing them. But assuming they are on it, there's no reason we can't wait. We tend to integrate new versions of Qt fairly soon after release. I kind of doubt we'll be taking in any significant Qt updates before 2.0, but it's not the end of the world if 2.0 goes out and menus don't read shortcuts. Just having the menus read at all is good, and of course, a lot of the shortcuts are pretty universally standard (Ctrl+S for save, etc). There's not that much in the menus available by shortcut that would be particular interesting for a blind user right now anyhow. Hmm, in fact, there is arguably *nothing* in the menus beyond the universal standard File menu commands worth reading to blind users right now. On the other hand, if this same bug basically means none of the work you do in other areas will succeed, then maybe it does make sense to spend some time on this. > Secondly, I've looked over the dialogs that you suggested (Open, Save > as, Save a copy, Save selection, Export, Export parts, Print) and they > look ok to me, from both the tabbing perspective and the screen-reader > feedback. Great. There is also, "Parts" - separate from Export Parts - but that seems OK too. Mostly you just need to be able to hit "New All" and then "OK". The rest of the dialog seems a little awkward to navigate by keyboard, but most people - sighted or otherwise - will never need the other controls. > I've almost finished with the tabbing in the tool bar. You can see the > commits in this branch here[3]. I've created a class that inherits the > QToolButton and adds support for tabbing. I've had two problems with > this class. First one, I could not find how to highlight the button > like when the cursor is hovering over it so, I got creative and I used > a graphic effect that changes the color of the Icon. I hope it is > okay, I will keep looking for how to do the highlighting. More good news! I'm sure the highlighting is possible. Well, maybe not "sure", but I strongly suspect it. Of course, for blind users, highlighting means nothing - hopefully the tool names read aloud! > For the second problem I created a bug report in the issue tracker[4]. > I've talked with Jaffar and he told me that is expected of the Return > or Space key to "press" the button selected by tabbing, but both key > are used as shortcuts. Yes, I saw this. Currently, as far as I know, Enter/Return is used only to add line breaks if a barline is selected. So it "shouldn't" conflict with use in the toolbar, although I understand that it does in reality. We do have other mode-specific shortcuts - like Space, actually, which starts playback except in lyric or chord entry mode. And I think the note entry mode shortcuts get special-cased - like how the number keys either set the duration in the toolbar for the *next* note (note entry mode) or else actually the duration of the current note (normal mode). So one way or another, I assume we can something similar set up for Enter/Return. BTW, you can't depend on keyboards having separate Enter and Return keys - mine doesn't, for example (I have no numeric keypad). Return/Enter is used kind of poorly in MuseScore in my opinion. It does indeed normally do the same as clicking or double clicking a selected object in other software, but there are any number of places in MuseScore where we fail to take advantage of this. I think this may become more of issue once we have full score keyboard navigation. I'd expect that once you click, say, a text item, Enter would be the same as double clicking, which puts it in Edit mode. But nothing happens. So we might have to give some serious thought to Enter behavior. Probably not worth it for 2.0 if we can find an interim solution. Like, maybe we provide a separate set of shortcuts for blind users to install, in which Enter is *not* used for anything else, so it is available for toolbar use. Providing a separate set of shortcuts for blind users may well make sense for other reasons too. For Space, how do other music/audio programs handle this? "Space" is almost universally mapped to Play / Pause in my experience. So I don't think we need to make that work. > What should I look at after I finish these? Good question. Maybe see if Jaffar has an opinion on anything else that could be done to improve basic usability for loading / playing / printing / saving scores for 2.0. If not, then maybe move on to keyboard navigation of the score itself? The biggest part of this is probably Implementing "next element" and "previous element" commands (which would of course get shortcuts) that can visit things other than notes and rests. Maybe also figure out a logical system for navigating up and down voices with a staff or between staves (that code is there and works, but the behavior is not necessarily optimal for someone trying to navigate a full score by keyboard alone). Then the status line as discussed in your proposal. I actually doubt any of the navigation work will be hard, but boy will that start to pay off - just being able to "read" scores via keyboard and screenreader would be huge, and an amazing alternative to Braille for some. The harder part, I assume, will be making the palette keyboard-friendly (or providing a keyboard-friendly alternative). And then there would be considerable work in making *all* the dialogs and windows needed to work with scores accessible - otherwise, an accessible palette is not as useful as it could be. Integration of conversion to Braille using third party converters (via MusicXML, most likely) is probably next after that. Not that I am assuming there is time in summer for all of this. Marc ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
