On 5/19/2014 5:09 AM, Andrei Tuicu wrote:
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.
Thanks, that looks like a good start. Even if things don't actually
work, it should at least get me more familiar with the concepts and how
things are maybe *supposed* to work.
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 only thing I think you should need for that is the ability to write
text to the status line and have that read aloud. I recall there was a
function to call if text is updated (I tried to implement this at one
point) but I couldn't get it to work.
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.
This is really really good info - exactly the sort of thing I hope to
see in your blog!
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. :)
Yes, I feel the same way.
Although I'm not yet sure what setAutoRaise does, I've tryied
using it and doesn't do what I need.
Too bad. It sure *seems* like the right answer. Have you tried this in
your simple test case (the application you created that shows Alt works
to trigger menu)?
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
Yes, I saw this too. I had never heard of this before; I'm accustomed
to Alt putting focus on the first menu only. I have no opinion on
whether we should support the new or old behavior.
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?
There are two kind of different notions of selection in MuseScore - and
another GSoC student (bartlomiej_lewandowski) is currently working on
revamping this. So you should probably keep in touch with him.
But for now, the two kinds of selection are the range, which works more
or less by having a start segment, end segment, and staff range
("segment" is a very basic concept in MuseScore - everything that
happens at a particular time position), and the single or multi-select,
which works by having a list of specific elements. The former is
indicated with a blue rectangle; the latter by actually making the
elements themselves blue. I am guessing it's the latter you mean. As
with many things in MuseScore, it appears to be a bit indirect. From
what I can tell, the main function is Element::setSelected(), which is
virtual and can thus be overridden for other element types. But these
functions mostly just set the "_selected" flag. The actual highlighting
is done separately, for example in Element::curColor(), which is called
by the various draw() methods for the different element types.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mscore-developer
