"Shift+[key]" shortcuts not working on 2.0.2 linux?

• Aug 1, 2015 - 12:57

I'm running into this issue on:

  • arch linux x86-64 official 2.0.2 release, both on laptop keyboard and external ps/2 keyboard, on Dell m4500
  • arch linux i686 official 2.0.2 release, on thinkpad x60s
  • trisquel 7 (ubuntu deriviative) self-compiled 2.0.2 from git, on MacBook 2,1

I first noticed this with ties: if I click a note and try to add I tie, I am unable to do so via "Shift+=". However I can insert the tie via the tie button in the toolbar. I can also insert the tie by enabling "NUMLOCK" and pressing the labtop key for '/' (which outputs '+' when numlock is enabled) on all my labtops. I am also able to insert a tie by pluging in an external computer keyboard with the numpad and using the numpad's dedicated '+' key.

Then I tested inputing cresc. & decresc. via Shift+, ('<') and Shift+. ('>'). Doesn't work. Then I definined some special shift+[key] such as Shift+8 ('*') to insert an octave below a pitch, and noticed that shortcuts I defined using a shifted key (e.g. !, @, #, $, %, ^, &, *) do not work on any of my linux machines when I type in the computer keyboard using shift+[key]. This used to work in earlier musescore versions on linux. So I am faily sure that something broke in last release regarding shift+[key] input. After trying dozens of times, I was able to one time produce a tie using [Shift]+=, but I think it was just by luck that I might have pressed the two keys at close enough time together that the event handler detected them as one combined keystroke.

My suspicion is that the event handling code is registering the pressing of "Shift" as its own seperate keystroke, but is not properly combining it with the next keystroke.

Note: This issue doesn't affect Ctrl+[key].
Note: This issue doesn''t happen with 2.0.2 on my Windows 7 x86-64 desktop machine.

Could someone on any other linux distro try to reproduce? Could someone on a Mac OS X try to reproduce?


Comments

I've determined that this issue results specifically from using QT's latest version 5.5, as after I downgraded my library in arch linux, it went away, just like #71001: 'loading' window at startup does not close if using Qt library version == 5.5.0 (which current arch linux release uses).

I will look into this more, in case there is changed behavior in QT 5.5 that musescore needs to adopt to, or in case there is a bug with QT 5.5.x I need to report to them.

Note: my Trisquel computer uses a self-compiled build of the latest git checkout of QT's library version 5.5.1, while my arch computers used version 5.5.0-1 when the error happens.

Do you still have an unanswered question? Please log in first to post your question.