Possible bug?

[KevinH]

How should Diacritics (dead keys) be treated. Should/can they be used alone in a keyboard shortcut?

[RbnJrg]

Well, these are the logs from my tests on the last Sigil beta:

With AltGr disabled:

Warning: Unable to open default EUDC font: "EUDC.TTE"
Debug: regenerating tag list
Debug: key():  "94"    '^'
Debug: text():  "\u001E"
Debug: nativeVirtualKey():  54
Debug: letter:  "^"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(ShiftModifier|ControlModifier)
Debug: MapVK_VK_TO_CHAR:  "54"   '6'
Debug: 

Debug: key():  "94"    '^'
Debug: text():  ""
Debug: nativeVirtualKey():  186
Debug: letter:  "^"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(ShiftModifier|ControlModifier)
Debug: MapVK_VK_TO_CHAR:  "2147483744"   '`'

"Ctrl + Shift + 6" works and in Shortcut field is grabbed "Ctrl + Shift + 6". When I press "Ctrl + Shift + 0" (or Ctrl + =), nothing appears in the Shortcut field, nothing is grabbed and, consecuently, the shortcut doesn't work. Finally, when I press "Ctrl + Shift + ^", in the Shortcut field is grabbed "Ctrl + Shift + some weird chars (two)". The shortcut doesn't work.

With the AltGr enabled, this is the log:

Warning: Unable to open default EUDC font: "EUDC.TTE"
Debug: regenerating tag list
Debug: key():  "94"    '^'
Debug: text():  "\u001E"
Debug: nativeVirtualKey():  54
Debug: letter:  "^"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(ShiftModifier|ControlModifier)
Debug: MapVK_VK_TO_CHAR:  "54"   '6'
Debug: 

Debug: key():  "94"    '^'
Debug: text():  ""
Debug: nativeVirtualKey():  186
Debug: letter:  "^"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(ShiftModifier|ControlModifier)
Debug: MapVK_VK_TO_CHAR:  "2147483744"   '`'
Debug: 

Debug: key():  "124"    '|'
Debug: text():  "|"
Debug: nativeVirtualKey():  49
Debug: letter:  "|"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(GroupSwitchModifier)
Debug: MapVK_VK_TO_CHAR:  "49"   '1'
Debug: 

Debug: key():  "64"    '@'
Debug: text():  "@"
Debug: nativeVirtualKey():  50
Debug: letter:  "@"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(GroupSwitchModifier)
Debug: MapVK_VK_TO_CHAR:  "50"   '2'
Debug: 

Debug: key():  "35"    '#'
Debug: text():  "#"
Debug: nativeVirtualKey():  51
Debug: letter:  "#"
Debug: modifiers:  QFlags<Qt::KeyboardModifier>(GroupSwitchModifier)
Debug: MapVK_VK_TO_CHAR:  "51"   '3'
Debug:

The result with the combinations of Ctrl + Shift are the same as the result with the AltGr disabled. But I also tested combinations with AltGr.
When I pressed AltGr + 1, in the Shortcut field appeared "1" (it should appear "|"). Of course, the shortcut didn't work. In the previous beta, in the Shortcut field was grabbed "|" (it should grab "Ctrl + Alt + |") and also didn't work. The same things happened when I pressed "Alt + 2" and "Alt + 3"; in the Shortcut field was grabbed "2" and "3" respectively (instead of "@" and "#", or the correct shortcut "Ctrl + Alt + @" and "Ctrl + Alt + #")

[KevinH]

So your Ctrl+Shift+6 now works

Your Ctrl+Shift+0 is being captured by your operating system for something (Zoom in or increase the volume or something) and that is why it never reaches Qt and Sigil.

Your Ctrl+Shift+` is a dead key (diacritic) which should create the ^. Dead keys are a known problem that we are working on. I am not sure how to treat them since they should be followed by another key to form a compound character.

And unless I am confused, I think BeckyEbook just explained that AltGr should really not be used in Shortcuts since it is used to form a character. With AltGR enabled it frees up Ctrl+Alt sequences to create more shortcuts since they are no longer being mapped to AltGr.

BeckyEbook is that correct?

The next issue is more basic:

Case A: Should a Shortcut sequence only include the sequence of keys actually hit as defined only by the main/primary symbol on that key?

Or

Case B: Should a Shortcut sequence include the impact of the modifiers (Control,Shift, Alt, etc) being used and map the primary key to its secondary (shifted, etc) definition and use that in the key sequence.

It can be argued either way. I am not sure one is more right than another.

On macOS, Case A is most often used. I am not sure about other platforms.

But Qt seems to want to use Case B, but then we have to almost guess to see if the Shift key was needed to create that character and if so to remove the shift from the key sequence so it can actually be used.


Thank you for testing and reporting back!

Let's wait to see what others think.

[BeckyEbook]

Originally Posted by KevinH

How should Diacritics (dead keys) be treated. Should/can they be used alone in a keyboard shortcut?

Dead keys should be blocked from being assigned to a keyboard shortcut as that would take away their sense of being in the keyboard layout.
This is not a huge requirement and the conscious user should not even think about using a dead key to define a hotkey in any application.
IMHO developers should not be held responsible for all user behavior.

By the way – in the keyboard shortcut definition window, you can define "ordinary" letters, for example A or B and such shortcuts, although they will be saved, they will not work (and luckily).

And unless I am confused, I think BeckyEbook just explained that AltGr should really not be used in Shortcuts since it is used to form a character. With AltGR enabled it frees up Ctrl+Alt sequences to create more shortcuts since they are no longer being mapped to AltGr.

BeckyEbook is that correct?

Yes. I think there are relatively simple keyboard layouts in Windows (e.g. Polish programmer or German) and those that are very complex, where AltGr is used to type complex diacritics. I've never dealt with them, but it's safer to assume that it's better not to use these shortcuts that have a "special effect" on your keyboard layout. I will repeat again – it does not make sense, because if we used such an abbreviation, we would take the possibility of inserting diacritics from our language (native or not) in the Code View or the Find & Replace window.

Case A: Should a Shortcut sequence only include the sequence of keys actually hit as defined only by the main/primary symbol on that key?

Or

Case B: Should a Shortcut sequence include the impact of the modifiers (Control,Shift, Alt, etc) being used and map the primary key to its secondary (shifted, etc) definition and use that in the key sequence.

I am for Case A, although in the case of "shifted" and only "shifted" I am able to accept Case B.

On my keyboard layout, where Shift+1=!:
* I prefer the notation Ctrl+Shift+1,
* I could understand Ctrl+! (since I can see an exclamation mark, I know I have to press Shift),
* I don't like Ctrl+Shift+!.

[RbnJrg]

Originally Posted by BeckyEbook

On my keyboard layout, where Shift+1=!:
* I prefer the notation Ctrl+Shift+1,
* I could understand Ctrl+! (since I can see an exclamation mark, I know I have to press Shift),

To me, any of both options are acceptable, meanwhile works

* I don't like Ctrl+Shift+!.

Yes, that's ugly and it doesn't reflect the reality.

[KevinH]

* I don't like Ctrl+Shift+!.
Yes, that's ugly and it doesn't reflect the reality.

And does not work, which is how we got started on this whole thing to begin with.

So I am going to modify the Windows code one more time to do the following:

- if GroupSwitchModifier is set, ignore the key sequence and return

- if MapVk... returns with the high bit set identifying it as a dead key, ignore the key sequence and just return.

I will push those changes for people to try.

[KevinH]

@BeckyEbook,
When you get a free moment, please build from master and let me know what you think.

If Enable AltGr is set, the new code should prevent any key sequence which uses AltGr from being generated.

If the MapVk... call indicates a dead key was going to be used in the sequence it will output debug info but return, preventing that key sequence from being generated.

This should prevent users from doing things that they probably shouldn't and prevent garbage chars and stuff from being written to screen or to the ini file.

Thanks

[BeckyEbook]

I confirm: it is great!
Locked AltGr shortcuts (which wouldn't make sense anyway) and dead keys.

[DiapDealer]

I'm able to create, save, but happily not use, single-key alphanumeric shortcuts. Was this always the case before?

[BeckyEbook]

Originally Posted by DiapDealer

I'm able to create, save, but happily not use, single-key alphanumeric shortcuts. Was this always the case before?

I suppose so. I checked on version 1.30 and the behavior is the same (you can assign a keyboard shortcut, but a single-letter one will not work anyway).

[DiapDealer]

Thanks for checking. I just don't use the feature enough to know the particulars of how it behaved before the recent changes.

[BetterRed]

Originally Posted by DiapDealer

I'm able to create, save, but happily not use, single-key alphanumeric shortcuts. Was this always the case before?

Yes, Sigil's always been thus - I discovered it accidentally years ago.

BR

[KevinH]

Okay, I think we may have solved this bug with what is in master yesterday. I spent some time looking at the Qt plugin source code in qtbase for Windows. It uses a ToUnicode() Windows call in their code and comments there indicate this call returns the wrong key for situations when Ctrl is used on some keyboard layouts, which explains RbnJrg's broken Ctrl+Shift+6 bug result.

Since Qt's internal code is broken here (according to their own comments) as well as various attempts at failed fixes according to github, the only correct way I can see is to use the MapVirtualKeyW(vk, MAPVK_VK_TO_CHAR) approach and use Case A (which is what is in master).

So unless there are issues with other platforms, I will consider this one fixed.

Thanks for all who tested and helped!

[BeckyEbook]

@DiapDealer, @BetterRed: I need to correct my last information about single-key alphanumeric keyboard shortcuts.
Single-key shortcuts work, but only when the focus is not in the Code View or some edit field. So they work when we have active other panels: Book Browser, Preview, Clips, or Table of Contents.

This is cool because I assigned the "S" key to "Add Semantic" and the shortcut works when I'm in Book Browser.

[DiapDealer]

Originally Posted by BeckyEbook

This is cool because I assigned the "S" key to "Add Semantic" and the shortcut works when I'm in Book Browser.

Good to know. I had to check to make sure it wouldn't interfere with a Book Browser file rename, but it doesn't. Qt seems to know to ignore any such requests when there's a text-input widget active.