Hello Marc,
I'm sorry for my late response, this week was my last week before finals
and there were a lot of deadlines for homeworks and tests that needed to be
passed in order to be accepted into the final exams.
The link that Jaffar sent to me for dropbox displays an error so I've
created a folder myself:
https://www.dropbox.com/sh/yry5phg526w4lul/AAAcGNRW0u_qZogMIUXMOIkXa
I've sent you the exe file using dropbox so you can see how the tabbing
works. I've mananged to remove from the tabbing order 4 of the 5 objects
that were irelevant at the moment, but I hope I didn't affect anything
while doing this. From what you've told me, there was no support for
tabbing, but I found that in scoretab.cpp and scoreview.cpp, the author(s)
explicitly setted some focus policies for StrongFocus(that means that
object can gain focus by mouse click, or by tabbing). In order to remove
those object from the chain I had to change the focus policy to ClickFocus.
I will continue to search for the last object. Also, just for the purpose
of the build that I've sent you, I've commented the instantiation of the
shortcut that toggled the system break so, now, if you select a button
using the tab key and press Return/Enter you will press the button. Now I'm
working at removing the shortcut for Return/Enter and hopefully I will
finish by tommorow.
I've looked more into the problem with the ALT key and so far I don't know
why for my test application it works and in MuseScore it doesn't. I've set
all the properties in the same way and I've checked and I've done the
creation of the menus in the same way. Also, I didn't find anything about
this in the documentation. I've asked on some forums about this and I'm
waiting for a reply. If I don't find an "official" solution, I can try
something similar to what I did with the tool bar.
Do you know if there is a date set for MuseScore 2.0 release? Beside the
two issues from above I think that I've finished with what meant
opening/saving/playing a score, but of course I'm waiting for your opinion
regarding what I've done. Do you have any ideas on what else should be
included in MuseScore 2.0? If not what would be the next step? From this
point anything I do involves either score editing or score navigation and
screen-reader feedback during navigation, so I don't think that we can find
anything here that will function properly on it's own until everything else
is finished, so that it can be integrated in 2.0. I could either start
working on the create new score diagram, or keyboard navigation for score,
or add all the buttons to the tabbing order in the main window and provide
a way for tabbing through the palettes.
2014-05-19 18:51 GMT+03:00 Marc Sabatella <[email protected]>:
> 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.
>
I've also tried to use the status bar when I was trying to make the
screen-reader tell the shortcuts for menu options and I think that it is
just a coincidence that for example in Sibelius that status bar displays
the same informations that the screen-reader says. As far as I can tell the
screen-reader doesn't see the status bar changes, for Qt at least. I
thought that score elements subclass QWidget, which would've made things
easier, but nevertheless I will find a way to do this.
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!
>
Sure! I will make a fully detailed post about this after you see the exe
and give me your ok on it. :)
>
> 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've tried, no luck there either...
>
> 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.
>
Jaffar said that he is in favour of the old behavior and said that form
what he knows, others preffer it too, so I will be implementing the old
behavior, if it is okay with you also.
>
> 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.
>
Thank you for the info! :)
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
