Mac version references incorrect shortcut #1539
Details for the issue
What did you expect to see?
Command + shift + click
What did you see instead?
Ctrl + shift + click
Useful extra information
The info below often helps, please fill it out if you're able to. :)
What operating system are you using?
What is your DB4S version?
Did you also
The text was updated successfully, but these errors were encountered:
Ahhh. I know we've made some changes to the displayed shortcuts since the last release (3.10.1), but I'm not sure if they're for OSX or not.
Ironically... I don't have handy access to an OSX box atm, so can't really test the nightly build myself either. Um... if you do have a few minutes to check after all, it would be useful.
Using QKeySequence(Qt::CTRL).toString() should be translated according to OS, either to Ctrl+ or Command+. Known problem: there are other tooltips referencing control key sequences but they are in *.ui files and this method cannot be used. Note: QKeySequence(Qt::CTRL + Qt::Key_Shift).toString() showed weird output under Linux.
I cannot test it under Mac, but according to Qt documentation, this particular case should be fixed now.
But there are other cases of key sequences referenced in tooltips or What's This info that cannot be fixed so easily. They are in *.ui files. If somebody knows have to fix these, please share here the tip:
Yeah, they are. Not sure how to add conditional compilation to those though, unlike with the .h/.cpp files where we do that fairly often.
eg (picking a random example here):
With conditional compilation we can say effectively "If this is being compiled on OSX, use XYZ bit of code. If instead it's Windows, use ABC". That'd work for displaying different shortcuts for different platforms.
Even without conditional compilation, if the tool tip was created at run time we could do the same thing. With the string embedded directly like that though... not sure.
Maybe we could add some kind of runtime/startup code that - for OSX only - overwrites those tooltip strings in the created app?
@ThinkDigitalRepair The case that you reported should be fixed in a nightly build. Could you confirm that the change done in source actually converts the key name to what a Mac user expects?
The cases of tooltip defined in the ui files are pending until we get a good idea on how to translate the key names to a native name.