On 5/18/2014 4:07 PM, Andrei Tuicu wrote:
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.
FWIW, there's mention of fixing issues in menus for Windows for 5.3.1 in
the blog article lasconic linked to.
> 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 will start by saying that I have no insight into how the accessibility
API works in Qt - that's why I was so keen on finding someone else eager
to work on this :-). So hopefully you'll be able to teach me some here
as you learn. I'll be of more help to you regarding MuseScore internals
as opposed to GUI stuff specifically.
With that out of the way, I'm confused as to why it was necessary to
subclass QToolButton just to get what I would have thought was standard
behavior. Since it wasn't working before, obviously something needed to
be done, but this seems odd to me. Now that you've obviously developed
some understanding of how these things work, maybe you could point me to
a good primer to help me get up to speed on how Qt accessibilty works in
general?
My first attempt at looking up info on this took me to the documentation
for QWidget, where it states:
* keyPressEvent
<http://qt-project.org/doc/qt-5/qwidget.html#keyPressEvent>() is
called whenever a key is pressed, and again when a key has been held
down long enough for it to auto-repeat. The*Tab*and*Shift+Tab*keys
are only passed to the widget if they are not used by the
focus-change mechanisms. To force those keys to be processed by your
widget, you must reimplementQWidget::event
<http://qt-project.org/doc/qt-5/qwidget.html#event>().
* ...
* The default implementation ofevent
<http://qt-project.org/doc/qt-5/qwidget.html#event>()
handles*Tab*and*Shift+Tab*(to move the keyboard focus), and passes
on most of the other events to one of the more specialized handlers
above.
This makes it sounds it sound like tabbing *should* have worked out of
the box unless we were already reimplementing QWidget::event(). And if
we were, wouldn't that be the place to add the proper Tab key handling?
It appears from the code in musescore.cpp that we weren't creating
QToolButtons directly - we were simply adding actions, which creates
QToolButtons automatically. I'm surprised this doesn't work already,
but obviously it doesn't. I don't suppose it's as simple as no tab
order having been defined? Probably not. Anyhow, your blog would be a
good place to record more info about what you've tried and not found
successful.
> First one, I could not find how to highlight the button
> like when the cursor is hovering over it
I looked at the QToolButton documentation and saw mention of the
setAutoRaise() method - sounds like this is *supposed* to do what you
want? It's supposed to be set by default when creating QToolButtons in
a QToolbar; maybe that means only when using the addAction method for
doing this. Perhaps calling this yourself is all you need?
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.
Do you mean a special state you'd enter upon pressing Tab that puts
focus on the toolbar and redefines keyboard shortcuts? If it's only for
Enter, I could probably live with this (others will probably disagree).
But I also wonder if maybe this is all unnecessary. Instead of trying to
make the toolbar itself accessible, maybe it's better just to make sure
everything on it has a shortcut accessible in "normal" mode? That's
kind of true already. I'm actually more concerned about ability to
reach the other sub-windows - Inspector, MuseScore Connect, the
Palettes, etc.
I wrote the first weekly report. It can be found here.
http://andreituicu.wordpress.com/2014/05/18/weeks0-tostring-menus-and-tool-bar/
Looks good! Although the title seems to display as raw Javascript?
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
