Another UPDATE.
Maurizio M. Gavioli wrote > In fact, a test with the whole code of MuseScore::enableInputToolBar(...) > commented out solved the shortcut conflict and showed the input tool bar > buttons correctly enabled/disabled. > > Question: > Is there a reason for keeping this function? I have continued testing a branch without the MuseScore::enableInputToolBar(...) method and I could not notice any problem. I have a branch more or less ready with the following improvements for TAB note input: *) fret mark entering set to simple [#] keys: [0] to enter fret '0', [1] to enter fret '1' and so on *) fret marks above 9 are entered pressing the individual digits: [1] and then [5] enters '15' *) string above, string below, next chord, prev chords all use simple arrows ([Up], [Down], [Left], [Right] resp.) *) pad note value shortcuts split between [normal|pitched entry|perc. entry] and TAB entry *) pad note value shortcuts for TAB entry set to [Shift][#]: [Shift][5] to set quarter, [Shift][4] to set quaver and so on. *) alternative pad note value shortcuts for TAB entry set to [NumPad][#]. *) "increase/decrease pad note value" set to [W] / [Q] A separate commit implements the only ad-hoc 'trick' I felt almost compelled to add: *) pad note value shortcuts for TAB entry are always disabled and the regular shortcuts are enabled in all input modes; rather than swapping the action enabled state, the key sequences of the TAB version are 'swapped' into the regular version when entering TAB entry mode and the original sequences are restored upon leaving it; this ensures that input tool bar buttons are also available in TAB entry mode. I believe this is the easiest possible setup for TAB input. It uses simple and obvious key sequence for the basic operations and provide 4 different methods for selecting pad note values: 1) [Shift][#] 2) [NumPad][#] 3) tool bar button 4) [Q] / [W] to increase None of them is perfect: 1) may have platform compatibility problems (my own keyboard does not detect [Shift][7] and I have no idea of what happens on French keyboards where the digits are already shifted) 2) requires a numpad (of course!) and currently it is not properly supported in the "Edit | Preferences | Shortcut" dlg box. 3) always works but mixing keyboard and mouse might be inconvenient 4) always works but requires keeping in mind the currently selected value or looking at the input tool bar However, having 4 different methods gives enough flexibility to cover most requirements, methink. I am going on with tests on this branch. If anybody notices potential problems in the above decriptions, PLEASE TELL ME! Thanks, Maurizio -- View this message in context: http://dev-list.musescore.org/Help-with-shorcuts-tp7577975p7578002.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
