Sorry, accidentally hit send without finishing my email.
2016-03-21 11:35 GMT+02:00 Andrei Tuicu <andrei.tu...@gmail.com>:
> Hello,
>
> I'm sorry if I wasn't clear before.
>
> 2016-03-21 5:44 GMT+02:00 Samadhi Poornima <
> samadhipoornima...@cse.mrt.ac.lk>:
>
>> Hi all,
>>
>>
>>
>> Here are some points that I need to clarify with you guys.
>>
>>
>> 2) Enable the use of keyboard to navigate to a text element or an
>> articulation or a crescendo marking.
>>
>> Use the existing “next element” code to traverse the "annotations" for
>> each ChordRest segment, the Articulations for each ChordRest, etc. Here
>> what is remaining, according to my opinion, is to implement a method to
>> dynamically alter the string which is displayed in the status bar to
>> include attached elements. Andrei, please do share your original plan to
>> implement this. I think it will be helpful here.
>>
>>
> First of all, there is a distinction that needs to be made between what is
> in the status bar and what the screen reader reports.
> The screen-reader usually says more then the it is in the status bar. In
> the status bar you will see only the selected element, the screen-reader
> will also say informations about attached elements.
> Visual impaired musicians will rely on screen-reader feedback only, they
> don't have access to the status bar itself. The status bar info is for
> non-visually impaired users. I hope that I explained this part clearly. If
> not please ask about specific points where you are not sure.
>
> Looking at the code from here:
> https://github.com/musescore/MuseScore/blob/master/libmscore/element.h#L587
>
> - Status bar: accessibleInfo
> - Screen-reader: screenReaderInfo + accessibleExtraInfo (attached
> elements)
>
>
> Ok, at this point here is what you have:
>
> - Screen-reader feedback when selecting an element (for *all*
> elements, including annotations, articulations, text elements, etc.).
> - Screen-reader feedback for all the attached elements when selecting
> notes/rests/barlines/clefs (might be others, but I don't remember
> specifically)
> - Status bar info on the selected element (for all elements).
> - A "nextElement" command for reading a score, that will select step
> by step notes/rests/barlines/clefs, basically all the elements that are
> standalone (non-attached). Using this command a user can traverse the score
> and find out about all the elements that are there, because the
> screen-reader will tell them about the current selected element and about
> all the elements attached to it.
>
> I don't think Marc was saying that you should modify the existing code for
> "nextElement" command (Marc, please correct me if I'm wrong here). You can
> look and see how I did things there in order to help you with your
> implementation.
>
> What you have to do:
>
> Create a command that can traverse *all* the elements. You don't need to
> change the existing code in order to have screen-reader feedback, just if
> you want to improve it, otherwise just selecting elements is enough. Users
> will use this command for editing the score, as opposed to the previous one
> which is used for reading only. My plan to implement this was as following:
> Look at the score as a tree data structure (which it is - each element has
> "children" and a parent: the Score object is the root, its children are the
> measures; the measures have as children segments, etc. Marc can give you a
> crash course in the structure of the score, he explained it to me as well)
> and implement a preorder traversal of this tree. My idea of algorithm was
> as following:
>
> 1. if nothing is selected: select the first element (you have code for
> selecting the first element)
> 2. if the current selected element has children, select the first one.
> 3. else go to parent and select the next child.
>
> I don't remember if there is an actual field in the Element class
> "children", so each type of element has children defined differently. There
> will also be some other corner cases for Spanners object, but you will
> figure this things out as you go.
>
>
>> 5) Support for other screen-readers- VoiceOver on OS X and also
>> Orca on Linux.
>>
>> When implementing support for VoiceOver on OS X , I will face a problem
>> since I do not own a Macintosh <https://en.wikipedia.org/wiki/Macintosh>
>> computer. Any word of advice on this issue will be helpful.
>>
>> As Lasconic said, if you don't have a Macintosh don't include this in
> your proposal. Focus on making everything work smooth with NVDA, then look
> at Orca (which is free and open source). If you finish everything else and
> have time to spare you can try to get an OS X. My advice is to try and look
> at ways to virtualise an OS X rather than trying to get an actual Macintosh
> computer. I don't know much about Apple products, but you may be able to
> find trial versions for OS X and there are free solutions for
> virtualisation that support it like VMWare player and VirtualBox. If not,
> you could try cloud solutions. I don't know if Amazon has support for OS X,
> but there is http://www.macincloud.com/ (never tried it, just googled it)
> and they seem to have a student pay plan. What I'm trying to say is that
> there might be solutions to get access for free to a OS X just for a number
> of day which are necessary to take a look at VoiceOver.
> JAWS is another alternative of screen reader on Windows that has a lot of
> users. It has a trial version that requires you to restart your computer at
> every 30 minutes or so, but at least you don't have to pay for it. :)
>
> In addition, I add the following point to my list.
>>
>>
>> 6) Make the palettes accessible to the screen reader.
>>
>> If we have the implementation for QAccessibleWidget for the Palette
>> object already, I think it remains only to implement the part which gathers
>> the information from the selected element and creates the string which is
>> displayed in the status bar and exposed to the Screen Reader.
>>
>> I think what I said was a bit confusing, in the code from my branch you
have to following:
- support for traversing the palettes using just the keyboard
- screen-reader feedback for the selected element
In addition you have in the MuseScores master branch from the offical
repository:
- support for adding the selecting element when Enter/Return is pressed
(implemented by Marc)
What you have to do here is:
- rebase/cherry pick my commits on the master branch and resolve the
eventual conflicts
- see if there are improvements to be made, or bugs to fix
And aside from this comes the idea for searchable palettes that you will
have to implement from scratch.
As explained at 2), there is no direct correlation between the status bar
and the screen reader feedback. The status bar is extra.
Once the QAccessibleWidget is implemented for a QWidget,
QAccessibleInterface for QObject and registered you have screen-reader
support. You might have to implement yourself a QAccessibleWidget depending
on how you design your search feature for the palettes.
Hope this helps!
Good luck!
Andrei
>
>>
>> Best Regards,
>>
>> Samadhi.
>>
>> On 20 March 2016 at 20:30, Lasconic <lasco...@gmail.com> wrote:
>>
>>> Just want to add that Braille output is a huge project by itself if we
>>> want to do it from scratch... So I wouldn't focus on this during a GSoC
>>> project. Your point 1, 2, 4 and 5 are more focused on MuseScore's
>>> accessibility.
>>>
>>> Regarding braille though...
>>> We could of course integrate with freedots, but the project is currently
>>> inactive. However it's the shortest road.
>>> I currently operate http://musicxml2braille.appspot.com/. Doing a REST
>>> API call from a plugin to get Braille out is probably doable. But, of
>>> course, the plugin needs to be accessible... Not sure it's the case for any
>>> plugin right now.
>>>
>>> lasconic
>>>
>>> 2016-03-20 7:48 GMT+04:00 Marc Sabatella <m...@outsideshore.com>:
>>>
>>>> On Sat, Mar 19, 2016 at 1:51 AM Samadhi Poornima <
>>>> samadhipoornima...@cse.mrt.ac.lk> wrote:
>>>>
>>>>
>>>>> 2). Enable the use of keyboard to navigate to a text element or an
>>>>> articulation or a crescendo marking.
>>>>>
>>>>
>>>> I think there is probably a pretty straightforward model for how this
>>>> could work, based on the existing "next element" code Andrei added (which
>>>> navigates clefs and barlines and some other elements, but not
>>>> articulations, text, or crescendos) but making sure to also traverse the
>>>> "annotations" for each ChordRest segment, the Articulations for each
>>>> ChordRest, etc. Here as elsewhere, feedback from actusal blind users would
>>>> be useful.
>>>>
>>>>> 3). Braille output- I plan on doing this by calling the FreeDots
>>>>> executable once the user enters the command to import the file to braille.
>>>>> However, this would not be the optimum solution to this since FreeDots is
>>>>> written in java.
>>>>>
>>>>
>>>> There are other concerns here too. FreeDots is a good thing, but it is
>>>> pretty limited in what it can do. There are other automatic or
>>>> semi-automatic MusicXML->Braille converter, each of which also has
>>>> limitations but different progrsams have different strengths and
>>>> weaknesses. There are a few people out there in the world who have done
>>>> fairly extensive study of these issues that you might want to consult, also
>>>> it might be good to contact the develoeprs of these tools to get a sense of
>>>> their plans for the future to see which tool might make the most sense for
>>>> us to focus our integration efforts on. Frankly, I'm not 100% convinced it
>>>> wouldn't someday be worth implementing out own Braille export, working
>>>> directly from our own score representation (although I recognize that this
>>>> becomes one more thing to maintain over time, so I don't make this
>>>> statement lightly).
>>>>
>>>> Marc
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Transform Data into Opportunity.
>>>> Accelerate data analysis in your applications with
>>>> Intel Data Analytics Acceleration Library.
>>>> Click to learn more.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>>> _______________________________________________
>>>> Mscore-developer mailing list
>>>> Mscore-developer@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Transform Data into Opportunity.
>>> Accelerate data analysis in your applications with
>>> Intel Data Analytics Acceleration Library.
>>> Click to learn more.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
>>> _______________________________________________
>>> Mscore-developer mailing list
>>> Mscore-developer@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>> _______________________________________________
>> Mscore-developer mailing list
>> Mscore-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>>
>>
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
