>
> But assuming they are on it, there's no
> reason we can't wait.
> 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.
>
> This is stricly for QActions contained in QMenu objects so this would not
affect other areas so it should not affect other areas. Also, they've
marked it as an important bug, so I'm assuming that this mean they will fix
it.
> > 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.
>
Sure, I will look into it.
>
> > 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!
>
> Yes, tool names, descriptions and shortcuts read aloud.
>
> 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.
>
I agree with this. Until now, all the programs that I've used have Space
mapped as shortcut for Play/Pause.
>
> > 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.
>
I agree and I have some ideas about how to do this.
Thank you, David, for your intervention!
The problem about Return/Enter key seems to be more complicated then I saw
it at first. As David said, other programs usually create a whole different
state for the program in order to allow keyboard navigation, although I
don't really like this and as I understood from you other developers are
also not big fans of states and modes, I think we should have a discussion,
I think on the IRC channel would be best, about this problem. The good part
is that the code that I've writen so far works for all the solutions that I
can think of, but what I write from now on I think depends a lot if a new
state is created, or not and it would affect also the global behaviour of
the program. I will also talk to Jaffar to see what he thinks of this and I
will try to make a list of advantages and disadvantages regarding this
subject and post it in the issue tracker. Now, the ALT button dosen't need
to be pressed in order for the tabbing to work. If you press the tab key,
it will go directly in the tool bar. For menus I intended to set the focus
on the first menu and then the moving should be done using the arrow.
Thank you for the article, Lasconic! :)
I wrote the first weekly report. It can be found here.
http://andreituicu.wordpress.com/2014/05/18/weeks0-tostring-menus-and-tool-bar/
------------------------------------------------------------------------------
"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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
