2014-05-19 2:56 GMT+03:00 Marc Sabatella <[email protected]>:
> 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.
>
That is ok. :) When I ask you things about Qt internals or accessibility it
is because I'm hoping you've encountered the same problem as me, but in
other contexts in your experience.
>
> 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?
>
Regarding a good primer, unfortunately there is no such thing... First of
all, the accessibility API does not address basic issues like tabbing, it
provides a way to generate screen-reader feedback for user defined custom
widgets. There is a general description about the class ierarchi here[0]
and a good example here[1], but for the moment this API is not usefull at
all. It might become usefull when I try to get screen-reader feedback for
score elements, although at the moment I think that I can do that without
the API, but I won't know for sure until I start working. The hard part
(for now) is to do things that should work "out of the box". I know that
I'm writing very few code, but I'm spending a lot of time researching how
to do things, by reading class documentation, articles, blogposts and forum
threads and finding a piece here, a piece there and trying to put them
together in order to get the expected result. The accessibility issues were
not addressed by many programers (as I see it) and there is very few code
examples, I'm usually finding what I'm searching for it unrelated contexts.
For example the QToolButton:
The first thing that I saw when searching about tabbing was the
setTabOrder(QWidget* a, QWidget* b) function from QWidget, and I've spent
some hours in trying to use it, but with no luck. Then I've read somewhere
unrelated about the focus and focusProxy properties of QWidget and I've
tried combinations of those with setTabOrder. Finally, I've found the
focusPolicy property which is for some subclasses of QWidget is set for
NoFocus(this is the case for QToolButton), by default and for other is set
to other values. There are only to values of this property that alow
tabbing: TabFocus and StrongFocus(which means that widget can gain focus by
either tabbing or my mouse click). If the focus policy doesn't have one of
those 2 values then widget is not included in the tabbing chain, so the
setTabOrder function doesn't have any effect. Next problem is that even if
the property is set to one of those values and the focus those change from
one QToolButton to another, the only way to know what widget had the focus
was to open the screen-reader and it would tell me the name and description
of the button that has focus. Also, pressing Enter/Return/Space did not
trigger the click event. For these last 2 problems I've subclassed the
QToolButton. I've bassically wrote the code that should have been in Qt in
the first place. How I've managed to find the informations to get the
expected behaviour is a whole different story. :)
As you can see it is a very time consuming process of "do{ search, try,
fail } until success"... At first I thought that this is my fault for being
new to Qt, but I'm starting to think that it is not the case, since others
can't help me either on dedicated forums. These is the reason why I've
decided to write some articles on the blog with my solutions regarding
these problems.
Although it is a bit hard, I do have to say that is very rewarding to know
that not only I'm working on adding support for accessibility in MuseScore,
but also with these "how to"s I will help others how are trying to provide
accessibility support. :)
>
> 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
> reimplement
> QWidget::event<http://qt-project.org/doc/qt-5/qwidget.html#event>
> ().
> - ...
> - The default implementation of
> event<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.
>
>
> As I said, the tabbing works, the default tabbing order is the order in
which the objects are created, but there was no highlighting and the button
wasn't clicked when the Return/Enter key was pressed. Yes the addAction
method creates a new QToolButton and sets the QAction received as parameter
as *default* action.
> > 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?
>
Although I'm not yet sure what setAutoRaise does, I've tryied using it and
doesn't do what I 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.
>
Yes, I was talking about a special state, but for when the ALT button is
pressed. You can see this for example in Sibelius, or for example in
Microsoft Word 2010 (and later). But after talking with Jaffar, I
understand that this is a somewhat new way of handling the keyboard
navigation and he would preffer if we don't do it this way, so my
suggestion is that I finish in the way that I've started (without a new
state) and after I show it to you, we decide how it's best. I'm a bit
confused here, because the default behavior for a Qt application is to
select the first menu when ALT key is pressed (I've tryied it and it
actually works for a new created application), but somehow MuseScore
overrides this behavior and I'm not sure yet here and how.
This might seem unrelated, but I do have some ideas about highlighting. Can
you please tell me where is the function that is called when a score
element (for example note) is selected?
>
>
>
> 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?
>
No, it is not JavaScript. It was my way of writing a funny title, instead
of "Week 0: Menus and Tool Bar". :D
If it not ok, I will change it.
Thank you!
Andrei
------------------------------------------------------------------------------
"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
