GSoC project idea "Accessibility"

Thanks for your interest in this project.  Do you have ideas on how this system you mention might work?  The main thing thst is not currently keybaord-acciessible now are the palettes.  One idea lasconic had was to make these searchable much liek the Symbols dialog (press "Z" to display) or the Instrument list (press "I") is, or for that matter the shortcut definition dialog in Edit / Preferences / Shortcuts.  So you could type the first couple of letters of the name of the palette item you want and the palettes would be filtered to show only elements whose names start those letter, and then you could navigate the resulting list with up/down keys and hit Enter to apply.  This much would probably actually be pretty easy to add.  But I think we need more than this - I think we need the ability to create regular user-assignable shortcuts as well, so if there are certain symbols you use a lot, you can apply them more directly.  I could imagine each palette cell having an optional "shortcut" property that let you assign shortcuts to any element you wanted.  Probably in reality there would be a single underlying command "apply palette element" that the shortcut system would use to apply the selected palette element, something like that.

There is also existing experimental code from another GSoC student who worked on this two years ago to make the palettes traversable by keyboard, and when I tested this code, it did seem to work pretty well.  it is not merged yet so you'd need to get his branch and build it, we can discuss this here or on IRC.

Another problem to tackle is score navigation.  The student I mentioned above implemented a lot and that was merged and is in 2.0.2 already, but we still don't have a way to select anything but notes, key and time signatures, clefs, and barlines.  That is, you can't use the keybaord to navigate to a text element or an articulation or a crescendo marking.  We need a new command that will navigate through these.

Braille output would be ncie, but simply exporting to MusicXML then converting using FreeDots is already possible to do by hand.  I think a more interesting integration with MuseScore might be to output the current selection to a Braille output device (physical devices with raised pins you can touch that respond in real time) so that as you navigate the score, the Braille device tells you want you are looking at.  This would be more efficient for many users than what we currently do, which is output a text decription to the status ine for a screenreader to read.

There are a few other user interface issues to sort out - shortcuts to move the focus from one window to the next (eg, from score to toolbar to inspector to selection filter).

Realistically, doing all of this in one summer is probably not feasiable, but these are ideas to cnsider.  i think keybaord control for palettes is especially high priority though, as it will also benefit sighted users (especially if we allow the assigning of shortcuts).

Marc

On Thu, Mar 17, 2016 at 8:43 AM WASam <[hidden email]> wrote:

Hi all,
I have already introduced myself, and I am interested in the GSoC project
idea, Accessibility.

In this project, I am planning to implement a keyboard based interface on
top of the museScore system. I thought of having a one-to-one mapping of
required events to key combinations without overlapping any existing
keyboard shortcuts. I am currently researching on it and any feedback or
guidance will be highly appreciated.
As per the “creating Braille music output” I am planning to use a tool like
FreeDots to  convert from MusicXML to Braille music.

Regards,
Samadhi.



--
View this message in context: http://dev-list.musescore.org/GSoC-project-idea-Accessibility-tp7579691.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Let me add that even sighted mouse addicts will appreciate a palette that can be filtered. The advanced palette has several 100 symbols and even in the basic palette, there are over 100 symbols. A lot of users have hard time to locate specific symbols.

lasconic

2016-03-17 19:07 GMT+04:00 Marc Sabatella <[hidden email]>:

Thanks for your interest in this project.  Do you have ideas on how this system you mention might work?  The main thing thst is not currently keybaord-acciessible now are the palettes.  One idea lasconic had was to make these searchable much liek the Symbols dialog (press "Z" to display) or the Instrument list (press "I") is, or for that matter the shortcut definition dialog in Edit / Preferences / Shortcuts.  So you could type the first couple of letters of the name of the palette item you want and the palettes would be filtered to show only elements whose names start those letter, and then you could navigate the resulting list with up/down keys and hit Enter to apply.  This much would probably actually be pretty easy to add.  But I think we need more than this - I think we need the ability to create regular user-assignable shortcuts as well, so if there are certain symbols you use a lot, you can apply them more directly.  I could imagine each palette cell having an optional "shortcut" property that let you assign shortcuts to any element you wanted.  Probably in reality there would be a single underlying command "apply palette element" that the shortcut system would use to apply the selected palette element, something like that.

There is also existing experimental code from another GSoC student who worked on this two years ago to make the palettes traversable by keyboard, and when I tested this code, it did seem to work pretty well.  it is not merged yet so you'd need to get his branch and build it, we can discuss this here or on IRC.

Another problem to tackle is score navigation.  The student I mentioned above implemented a lot and that was merged and is in 2.0.2 already, but we still don't have a way to select anything but notes, key and time signatures, clefs, and barlines.  That is, you can't use the keybaord to navigate to a text element or an articulation or a crescendo marking.  We need a new command that will navigate through these.

Braille output would be ncie, but simply exporting to MusicXML then converting using FreeDots is already possible to do by hand.  I think a more interesting integration with MuseScore might be to output the current selection to a Braille output device (physical devices with raised pins you can touch that respond in real time) so that as you navigate the score, the Braille device tells you want you are looking at.  This would be more efficient for many users than what we currently do, which is output a text decription to the status ine for a screenreader to read.

There are a few other user interface issues to sort out - shortcuts to move the focus from one window to the next (eg, from score to toolbar to inspector to selection filter).

Realistically, doing all of this in one summer is probably not feasiable, but these are ideas to cnsider.  i think keybaord control for palettes is especially high priority though, as it will also benefit sighted users (especially if we allow the assigning of shortcuts).

Marc

On Thu, Mar 17, 2016 at 8:43 AM WASam <[hidden email]> wrote:

Hi all,
I have already introduced myself, and I am interested in the GSoC project
idea, Accessibility.

In this project, I am planning to implement a keyboard based interface on
top of the museScore system. I thought of having a one-to-one mapping of
required events to key combinations without overlapping any existing
keyboard shortcuts. I am currently researching on it and any feedback or
guidance will be highly appreciated.
As per the “creating Braille music output” I am planning to use a tool like
FreeDots to  convert from MusicXML to Braille music.

Regards,
Samadhi.



--
View this message in context: http://dev-list.musescore.org/GSoC-project-idea-Accessibility-tp7579691.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Hello, Marc, Lasconic, Samadhi!

The code that Marc is talking about for traversing palettes and also for providing screen reader feedback for it's elements can be found in this branch:

https://github.com/andreituicu/MuseScore/tree/accessible_palettes

As Marc said, the code is pretty old, so if you want to use it you would have to try it out, see what works and what doesn't.

A very good starting point for you, Samadhi, if you are interested in this project is to install the NVDA screen-reader (Windows only) and to see what is there in MuseScore and what is not, what can be done with the keyboard and what needs to be added. You can find a page in the handbook regarding this wrote by Marc here: https://musescore.org/en/handbook/accessibility

MuseScore works best with NVDA, because that is what I used when I participated in GSoC 2014. If you start working on this project, you will find that each screen-reader has its own "personality". :) Meaning, they react differently to the events generated by Qt and report differently the information that is available. Support for other screen-readers would be also very welcomed from users point of view, I managed to do a bit a for JAWS, but a lot of users asked for VoiceOver on OS X and also Orca on Linux is a good alternative because it's free.

At some point I also compiled a list for myself for what MuseScore needs from the accessibility point of view and small notes on how can they be implemented, you can find that here:

https://docs.google.com/document/d/14c7W5w0oT03mIqCQehaAEy43r0iz5imfVZrCuOGOmnQ/

Feel free to use anything from my list, or my repository (I don't remember if there is more useful unmerged code) in your GSoC proposal, but you should discuss everything in advance with Marc and Lasconic, because I haven't been up to speed with the latest MuseScore development and they know better what is top priority.

Thank you,

Andrei

2016-03-17 17:23 GMT+02:00 Lasconic <[hidden email]>:

Let me add that even sighted mouse addicts will appreciate a palette that can be filtered. The advanced palette has several 100 symbols and even in the basic palette, there are over 100 symbols. A lot of users have hard time to locate specific symbols.

lasconic

2016-03-17 19:07 GMT+04:00 Marc Sabatella <[hidden email]>:

Thanks for your interest in this project.  Do you have ideas on how this system you mention might work?  The main thing thst is not currently keybaord-acciessible now are the palettes.  One idea lasconic had was to make these searchable much liek the Symbols dialog (press "Z" to display) or the Instrument list (press "I") is, or for that matter the shortcut definition dialog in Edit / Preferences / Shortcuts.  So you could type the first couple of letters of the name of the palette item you want and the palettes would be filtered to show only elements whose names start those letter, and then you could navigate the resulting list with up/down keys and hit Enter to apply.  This much would probably actually be pretty easy to add.  But I think we need more than this - I think we need the ability to create regular user-assignable shortcuts as well, so if there are certain symbols you use a lot, you can apply them more directly.  I could imagine each palette cell having an optional "shortcut" property that let you assign shortcuts to any element you wanted.  Probably in reality there would be a single underlying command "apply palette element" that the shortcut system would use to apply the selected palette element, something like that.

There is also existing experimental code from another GSoC student who worked on this two years ago to make the palettes traversable by keyboard, and when I tested this code, it did seem to work pretty well.  it is not merged yet so you'd need to get his branch and build it, we can discuss this here or on IRC.

Another problem to tackle is score navigation.  The student I mentioned above implemented a lot and that was merged and is in 2.0.2 already, but we still don't have a way to select anything but notes, key and time signatures, clefs, and barlines.  That is, you can't use the keybaord to navigate to a text element or an articulation or a crescendo marking.  We need a new command that will navigate through these.

Braille output would be ncie, but simply exporting to MusicXML then converting using FreeDots is already possible to do by hand.  I think a more interesting integration with MuseScore might be to output the current selection to a Braille output device (physical devices with raised pins you can touch that respond in real time) so that as you navigate the score, the Braille device tells you want you are looking at.  This would be more efficient for many users than what we currently do, which is output a text decription to the status ine for a screenreader to read.

There are a few other user interface issues to sort out - shortcuts to move the focus from one window to the next (eg, from score to toolbar to inspector to selection filter).

Realistically, doing all of this in one summer is probably not feasiable, but these are ideas to cnsider.  i think keybaord control for palettes is especially high priority though, as it will also benefit sighted users (especially if we allow the assigning of shortcuts).

Marc

On Thu, Mar 17, 2016 at 8:43 AM WASam <[hidden email]> wrote:

Hi all,
I have already introduced myself, and I am interested in the GSoC project
idea, Accessibility.

In this project, I am planning to implement a keyboard based interface on
top of the museScore system. I thought of having a one-to-one mapping of
required events to key combinations without overlapping any existing
keyboard shortcuts. I am currently researching on it and any feedback or
guidance will be highly appreciated.
As per the “creating Braille music output” I am planning to use a tool like
FreeDots to  convert from MusicXML to Braille music.

Regards,
Samadhi.



--
View this message in context: http://dev-list.musescore.org/GSoC-project-idea-Accessibility-tp7579691.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

On Sat, Mar 19, 2016 at 1:51 AM Samadhi Poornima <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

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. 

      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 computer. Any word of advice on this issue will be helpful.

 

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.

 

Best Regards,

Samadhi.

On 20 March 2016 at 20:30, Lasconic <[hidden email]> 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 <[hidden email]>:

On Sat, Mar 19, 2016 at 1:51 AM Samadhi Poornima <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Andrei explained things well.  I'll just add a couple of things:

Whether we modify the existing "next element" command or add a new one is not important; actually we should get user feedback on that.  If we do add a new one, there would be a choice between a single command that traverses all commands (and thus one would use *instead* of the existing command if one wanted to traverse all elements), or perhaps a command that just traverses the "children" of a given element.  Any of these designs could conceivably work.  And indeed, there is no single "child" concept in the Element class; different elements have different children.  We *could* conceivably add a new virtual function "children" to the Element class and instantiate it as necessary for each sub-class that actually has child elements.

Marc

On Mon, Mar 21, 2016 at 3:47 AM Andrei Tuicu <[hidden email]> wrote:

Sorry, accidentally hit send without finishing my email.

2016-03-21 11:35 GMT+02:00 Andrei Tuicu <[hidden email]>:

Hello,

I'm sorry if I wasn't clear before.

2016-03-21 5:44 GMT+02:00 Samadhi Poornima <[hidden email]>:

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 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 <[hidden email]> 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 <[hidden email]>:

On Sat, Mar 19, 2016 at 1:51 AM Samadhi Poornima <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Hi all,

Taking into account all the facts you guys pointed out, I created my draft proposal. You can view it here.

https://docs.google.com/document/d/1ofiRCitgEps9N8rvWYcCjmgdyu4QvUO-RBFKhoduXX4/edit?usp=sharing 

Waiting for some feedback!

Best Regards,

Samadhi.

On 21 March 2016 at 21:16, Marc Sabatella <[hidden email]> wrote:

Andrei explained things well.  I'll just add a couple of things:

Whether we modify the existing "next element" command or add a new one is not important; actually we should get user feedback on that.  If we do add a new one, there would be a choice between a single command that traverses all commands (and thus one would use *instead* of the existing command if one wanted to traverse all elements), or perhaps a command that just traverses the "children" of a given element.  Any of these designs could conceivably work.  And indeed, there is no single "child" concept in the Element class; different elements have different children.  We *could* conceivably add a new virtual function "children" to the Element class and instantiate it as necessary for each sub-class that actually has child elements.

Marc

On Mon, Mar 21, 2016 at 3:47 AM Andrei Tuicu <[hidden email]> wrote:

Sorry, accidentally hit send without finishing my email.

2016-03-21 11:35 GMT+02:00 Andrei Tuicu <[hidden email]>:

Hello,

I'm sorry if I wasn't clear before.

2016-03-21 5:44 GMT+02:00 Samadhi Poornima <[hidden email]>:

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 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 <[hidden email]> 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 <[hidden email]>:

On Sat, Mar 19, 2016 at 1:51 AM Samadhi Poornima <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Hi all,

Regarding the implementation of  support for screen-reader, Orca on Linux, I am planning to use qt-at-spi in order to bridge QAccessible API’s to the AT-SPI 2 protocol enabling MuseScore to be used with Orca.

I also added that to the proposal, but If you guys have any better alternatives please let me know.

Best Regards!

Samadhi.

On 22 March 2016 at 20:13, Samadhi Poornima <[hidden email]> wrote:

Hi all,

Taking into account all the facts you guys pointed out, I created my draft proposal. You can view it here.

https://docs.google.com/document/d/1ofiRCitgEps9N8rvWYcCjmgdyu4QvUO-RBFKhoduXX4/edit?usp=sharing 

Waiting for some feedback!

Best Regards,

Samadhi.

On 21 March 2016 at 21:16, Marc Sabatella <[hidden email]> wrote:

Andrei explained things well.  I'll just add a couple of things:

Whether we modify the existing "next element" command or add a new one is not important; actually we should get user feedback on that.  If we do add a new one, there would be a choice between a single command that traverses all commands (and thus one would use *instead* of the existing command if one wanted to traverse all elements), or perhaps a command that just traverses the "children" of a given element.  Any of these designs could conceivably work.  And indeed, there is no single "child" concept in the Element class; different elements have different children.  We *could* conceivably add a new virtual function "children" to the Element class and instantiate it as necessary for each sub-class that actually has child elements.

Marc

On Mon, Mar 21, 2016 at 3:47 AM Andrei Tuicu <[hidden email]> wrote:

Sorry, accidentally hit send without finishing my email.

2016-03-21 11:35 GMT+02:00 Andrei Tuicu <[hidden email]>:

Hello,

I'm sorry if I wasn't clear before.

2016-03-21 5:44 GMT+02:00 Samadhi Poornima <[hidden email]>:

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 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 <[hidden email]> 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 <[hidden email]>:

On Sat, Mar 19, 2016 at 1:51 AM Samadhi Poornima <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Hello,

I would also like very much for this project to continue, even if I am not able to help with more than pointers and ideas, at least until I finish my Bachelor thesis. I think it is a project that has a great impact.

2016-04-27 21:33 GMT+03:00 Marc Sabatella <[hidden email]>:

I am sorry your project did not get selected.  We had a limited number of slots to fill so there were difficult choices to make.  But this project is very import to me personally, so I'm definitely still wanting to help with this.

Probably what makes sense is to look at the individual problems to be solved and come up with a plan as to who will do what and in what order.

I think the two most important areas to look at first are a way to search the palettes - akin to the search box we have in the instrument list or symbols dialog - and a way to assign direct keybaord shortcuts to individual palette elements.  My sense is that these two are probably pretty unrelated in terms of actual implementation, but should be considered together in terms of design.

Andrei's as-yet-unmerged work implemented a third approach - makign the *existing* palette navigatable by keybaord - but I'm not sure that ends up being necessary if we do the other two things.  That is, we were treating "keyboard access to palette" as an end goal and he implemented that directly.  But if I look at the goals a bit differently:

1) an easy way to find things on palette

2) a fast way to apply things from palette

3) a way to enter palette items with keyboard only

Palette navigation really doesn't help with 1) or 2).  But searchable palette and shortcuts pretty much address 3) without the need to modify the existing palette code or behavior.

I agree with the fact that making palettes searchable and shortcuts will be extremely helpful when it comes to editing and not only for the visually impaired users. Traversing all palettes every time one wants to add an element to the score would be extremely slow. I still think that we'd want to give the users the option to traverse each element if they want to, but I might be biased and I might change my opinion once I see the actual the previous features working. :)  Since most of the visually impaired users will be new to MuseScore, I remember when I personally opened MuseScore for the first time, after I looked a bit through the toolbar, then I expanded all the palettes and I spent some time looking what is there. I think that this is an important step in learning to use MuseScore. In the end, I think what I am trying to say is that each approach (traverse/search/shortcuts) will make the palettes usable by visually impaired users without the other two, but if we want to give them a seamless experience, we need to have all of them. As I said, I might change my opinion once I see things working. Of course, it is always better to ask the users. Is MuseScore still working with RNIB?

In terms of importance and impact, this would be the best place to start, but probably not the easiest.

 

Then, of course, there is also the "next element" command for full navigation of all elements - probably pretty easy to implement, actually,  basically just as your proposal outlines.

I don't know if it will be that easy to implement, I think that there will be a lot of corner cases to take into account, but it is a good place to learn a big part of the MuseScore's libmscore internals.

 

And a way to move keybaord focus from window to window - also hopefuly easy but will require familiarity with Qt and maybe Andrei has some good insight here.

I think this would be the easiest to implement. I would do this as follows:

1. Create a Singleton class FocusManager (or something like that) which will store a circular linked list of QWidgets (or QObjects, you will have to find the base class of all the MuseScore's subwindows that you would like to move keyboard focus to). It will have to offer methods for adding/removing windows and moving the focus to the next/previous windows. I guess that you could avoid using the Singleton and store a pointer to the FocusManger object in the MuseScore object, which if I remember correctly has only one instance and it is available from everywhere. I don't know which approach is better.

2. Either create a class FocusManageable which in the constructor/destructor adds/removes the current object to/from the FocusManager's list and make each of the MuseScore's subwindow classes inherit this class as well, or directly add the appropriate call in the existing constructor/destructor. I personally prefer the first approach, but you might want to check this with Lasconic and Marc.

3. In the methods for moving the focus to the next/previous window from the FocusManager you would need to traverse the linked list to find which of the windows contains the object that currently has focus. To find out what is the object that currently has focus you can use qApp->focusWidget() and to find if a window contains that object you would use the isAncestorOf method, like here .

4. Once you've found which of the windows has focus, you then go through the list to find the next one that is visible and you set focus to it, somewhere along these lines. Note: you will have to call the activateWindow function as well, because Windows doesn't allow a window that is not active to gain focus.

5. Create two MuseScore commands with shortcuts to call the methods for moving the focus to the next/previous subwindow from the FocusManager object.

There might be some things that I haven't consider, but you would find those once you start the implementation.

Hope this helps,

Andrei

 

Marc

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mscore-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mscore-developer