Possible bug?
 

I made a clip to comment lines in css stylesheets. The clip is:

and I assigned the shortcut "Ctrl + Shift + 1". Well, it doesn't work. When I press the shortcut in a stylesheet, it happens nothing.

By the way, is there any way that in the Keyboard Shortcut dialog, instead of "Clip 1, Clip 10, ..., etc., etc.", it appears the name of the clips?

I'm assuming you have something highlighted when you use the shortcut?

It works for me. Both the original Crtl+Alt+1, and Ctrl+Shift+1 (which is actually Ctrl+! for all practical purposes on my machine/keyboard.

Perhaps that shortcut is being used by some system-level process on your machine?

I have the same >>>Saved SEARCH <<< and it works great on the highlighted text. :D
(I did not assign a hot key)

Can you verify that the clip is working in general (from the clip bar and not via the shortcut)?

Also works just fine for me. Perhaps something else has been assigned that shortcut key sequence, as DiapDealer suggested?

Of course :D

The issue seems to be when I use a combination of Ctrl+Shift+Number (for example, "Ctrl+Shift+8", that also is "Ctrl+(" in my keyboard) or a combination of "Ctrl+Shift+Right/Left". In all those case, the shortcut doesn't work. However, there is no problem when I employ "Ctrl+Shift" with a letter, or a "Ctrl+Shift+F#" key. If the issue can't be duplicated, then the problem must be with my keyboard.

And regarding my other question, that in the Keyboard Shortcut dialog, instead of "Clip 1, Clip 10, ..., etc., etc.", it appears the name of the clips. Maybe it can be possible to use the Sigil_clip.ini to replace names in the Shortcut dialog.

It doesn't work for me (probably for years), but I know a workaround.
When in Preferences> Keyboard Shortcuts I can see Ctrl+Shift+! then I close Sigil, manually edit the sigil.ini file, find such a wrong entry and correct it on Ctrl+Shift+1, save the sigil.ini file and it's OK.

IMHO is not strictly a Sigil error, but a Qt error.

Yes, the clip is working. In fact, now I have assigned the shortcut "Ctrl+*" and works fine. The problem is that I can't assign any secuence based on Ctrl+Shift+Number (Ctrl+Number works ok) or Ctrl+Right/Left, Ctrl+Shift+Right/Left. No problem with others combinations. But as I said, if the issue can't be duplicated, then must be something with my system or keyboard.

Is the '!' the shift of the key with '1' on it? Why would Qt detect the numeral 1 as an !?

Is this a Windows Qt bug or keyboard specific?

Wow, it works! I did exactly what you wrote and the combination "Ctrl+Shift+1" worked! Well, at least there is a way to assign as a shortcut the combination "Ctrl+Shift+Number". Thanks for posting your workaround.

Yes.
I have exactly the same symptoms as @RbnJrg, but due to my Polish keyboard layout, I am used to all kinds of keyboard shortcuts problems.
Over the years, I've seen a few submissions on the Qt forum, but they probably haven't received too much priority.

https://i.imgur.com/yMSF0Wh.png

I don't know. I think that in all keyboards when you have to type the symbol "!", you have to press "Shift+1". So I believe that Qt must think that we are pressing the combination Ctrl+!. I say that because if in Sigil.ini, I write as a shortcut "Ctrl+!" or "Ctrl+Shift+1", both ways work. But not "Ctrl+Shift+!". But when in the shortcut dialog we press "Ctrl+Shift+1", there is written "Ctrl+Shift+!", the combination that is not working. So I don't know where is the origen of the issue.

A bit of quick testing with a programmable keyboard showed that that I would need a key where ! was the unshifted character for Ctrl+Shift+! to work. Since I went quick and dirty and swapped the ! and 1, Ctrl-1 also worked. Now if I could work out how to use the modifier keys in a useful fashion outside out running APL or LISP interpreters.

So as DiapDealer has already stated, Ctrl+Shift+1 must equate to Ctrl+! if the '!' is accessed via the shift of the 1.

So not all possible combinations of key sequences can be assigned as they are in fact not unique.

In our Sigil Preferences KeySequence routine we only have access to the modifiers used and the resulting text produced. So we detect Ctrl+Shift+1 as Ctrl+Shift+! since it detects the modifiers and the text function returns '!' not '1'.

We would have to have access to a keyboards mapping / layout to handle this properly and write it out as Ctrl+! or Ctrl+Shift+1 BUT not as Ctrl+Shift+!

I will look to see if raw scan codes can be used somehow.

Yes, but also you should do the same not only with the case of Ctrl+Shift+! but also with Ctrl+Shift+", Ctrl+Shift+$, Ctrl+Shift+%, Ctrl+Shift+&, etc., etc. If we were able to edit the imput in the shortcut dialog by ourself (so far, is not allowed), the issue is solved. It would a piece of cake for us to change Ctrl+Shift+! into Ctrl+Shift+1 (but we can't overwrite the "!" with "1").

In Sigil Prefs (see Sigil/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp) when assigning key sequences we capture the QKeyEvent and the key's generated key() and text(). The key() function is supposed to be independent of modifiers included according to Qt docs.

In our routine called translateModifiers() in this file we check to see if we need/should include the Shift Modifier by looking at the unicode character groupings of the text() which should be a '!' point (part of the Other Punctuation unicode group) and so the shift modifier should *not* be added in and the Ctrl+Shift+1 should be detected as Ctrl+! and that is what should be written to the ini file.

But that does not appear to be true somehow.

I would love to see what QKeyEvent 's key() and text() returns immediately after setting nextKey in KeyboardShortcutsWidget::handleKeyEvent() when Ctrl+Shift+1 is entered on impacted machines so we can see why this is not being handled properly.

Thanks!

When I hit the Ctrl+Shift+1 keys in Sigil's Keyboard shortcuts dialog in Linux, it is Ctrl+! that actually gets registered (and appears in the .ini file) and works to successfully trigger the clip replacement.

When I do the same thing in Windows, it is Ctrl+Shift+! that gets registered (and appears in the .ini file) and FAILS to successfully trigger the clip replacement.

Debug:

It is 100% backwards on Windows than what the Qt docs say.

The key() should not reflect modifiers and it should be "1" not "!".
The text() should reflect all modifiers and should return "!" since Shift+1 is the "!" not "1".

So these functions are reversed somehow. If it is like that for all Windows keyboards we can reverse the values for just Windows. For macOS and Linux this works as documented by Qt.

How strange!

Actually on macOS it is different. If I click Command+Shift+1 I get Ctrl+Shift+1 and not Ctrl+! in the field in Sigil's Preferences and in the ini file.

So all platforms appear to be slightly different.

KevinH

ps: Here is what happens on macOS:

Debug: key(): "49" '1'
Debug: text(): ""
Debug: modifiers: QFlags<Qt::KeyboardModifier>(ShiftModifier|Control Modifier)

So here the text() call is wrong completely as it is a null string but at least the key() call returned the value WITHOUT modifiers so the code just worked.

I found the following in the Qt Docs ...

and


So this is pretty much a platform specific nightmare. And it appears to be based on other things as well.

On macOS here are some test cases:

- entered small h:
key() returns 'H', text() returns 'h', no modifiers
result: H

- enter Shift + H:
key() returns 'H', text() returns 'H', shift modifier
result: Shift+H

- entered Ctrl+Shift+1:
key() returns '1', text() returns '', ctrl and shift modifiers
result: Ctrl+Shift+1

- entered Meta+Shift+1:
key() returns '!', text returns '', shift and meta modifiers
result: Meta+Shift+! (this is wrong I think!)

- entered Alt+Shift+1:
key() returns '!', text() returns '?', alt and shift modifiers
result: Alt+!

So it appears on macOS the text() value returned is either the unicode character formed, or a null string, or a "?" depending on what other modifiers are being used at the time.

The bottom line is that the existing code seems to work on Linux as expected, seems to work on macOS - most of the time but text() is basically not as advertised. And on Windows it does not seem to work for at least some modifiers on at least some Windows platforms with some key combinations.

I would love to see the output of key() and text() and modifiers() and the result stored for all of the test cases shown above on Linux and Windows so that I can begin to understand what it is going on and what commonalities exist so we can rewrite this.

The official Qt docs are clearly worthless in this regard.

BTW: To make things even worse on macOS
- using the apple/command key results in the Ctrl modifier being set
- using the option key results in the Alt modifier being set
- using the control key results in the Meta modifier being set

Thanks,

KevinH

Debug:

Thanks BeckyEbook. Btw, the meta modifier is supposed to be the Windows key.
So it appears that Windows treats Ctrl + Shift plus key differently in just some cases which is just as strange as macOS.

Very odd. I am going to have to really think about how to do this that will work for all keyboard layouts.

I have looked and looked at this. The only way that I can find to really do this properly is to know the keyboard layout being used so that we know if the key()/text() generated requires the SHIFT key or not.

For the US this is easy as the following holds true for both the QWERTY and DVORAK keyboards:

and seems to be the norm BUT for international keyboard layouts, this is simply not true!

So there really is no way to tell when shift is pressed and a key() of '!' is returned (which violates the Qt docs since it should ignore modifiers on US style keyboard layout) and text() returns '1' (which again violates the Qt docs since a '1' was NOT the generated unicode text) that it is okay to fix it without knowing the exact keyboard layout.

I did search for how to determine the keyboard layout being used in Qt but according to the search results this can not be done since it happens under the Qt layer.

So I think we will have to live with this mess (of needing to fix the ini file by hand) until Qt gets off its butt and actually fixes its code to do what the docs/api says it should do. If all platforms followed the api, then detecting if the shift would be at least theoretically possible.

But right now it is broken for Ctrl+Shift on Windows and broken for Meta+Shift on macOS. I have no other data for Linux as of yet other than it seems to handle Ctrl+Shift better than Windows.

A thought ...

if I compare the key() to the text() and they fit into the QWERTY and DVORAK table above, then I assume it would be safe to fix things.

If anyone has an intl keyboard, it would be interesting to see a similar table

Here is an image of the layout of my keyboard (latinoamerican):



Wouldn't be possible for us to edit the entered shortcut in the Keyboard Shortcut dialog? So, the correct input would be stored in the .ini file.

@KevinH:
Perhaps the solution for Windows would be to use the system MAPVK_VK_TO_CHAR check?

I quote from the documentation:
Then we will know what key was really pressed with Shift.

I did a try and I think it should work, but you would need to add a condition (Windows only) that would specify modifiers + unshifted key (if one of the modifiers is Shift) and then display that value in the Preferences window and save it to sigil.ini.

Add to void KeyboardShortcutsWidget::handleKeyEvent(QKeyEvent *event)

Debug:

Looks promising! Where is vk getting set to pass it in? Are you using event->key() for it? Or event->nativeScanCode() for it?

const auto vk = event->nativeVirtualKey();

I will try coding that up tomorrow in master. There are similar virtual key codes for macOS but converting them to a char is not straightforward as the Windows call approach you found.

I should have some time coming up to test what you guys are cooking up on both virtual and physical Linux and Windows machines. Just let me know what's needed.

Do we need to consider a cross-platform utility class/function that we can easily call from anywhere, or is it something that will probably be OK with a bit of well-placed MainWindow ifdef-ing?

It all depends. I would love to create a utility routine to create a table of keycode, shift used, and nativeVirtualKeyCode (basically a quick and dirty keyboard mapping of base and shifted keys).

This would work crossplatform. I just do not know how the nativeVirtualKeyCode is determined or how to create a map given those values are only provided inside a QKeyEvent and we can not force people to hit each key once with and without shift just to build a table each time Sigil is started.

Perhaps let's just focus on getting Windows fixed as macOS seems to function okay with the current code for the most part.

Anything helpful or relevant here?

https://github.com/kovidgoyal/calibr...eyboard.py#L33

https://github.com/kovidgoyal/calibr...rtcuts.py#L109

Yes!
Kovid is handling knowing if a shift is needed or not by checking if the key when uppercased == the key when lowercased. That should be true for all numbers and punctuation and all special symbols.

It is very similar to the code we use - ours uses unicode character classes - to accomplish something close.

Let's give Kovid's way a try to see how that works.

Excellent! I have my fingers crossed.

Nope! That code is very broken on macOS. It removes the Shift from the sequence Ctrl+Shift+1 since all digits have no upper or lower and so meet the criteria for removing the SHIFT.

Perhaps it will help Windows. I will try that next.

Okay, I have ifdef'd calibre's approach for use on Windows only. I pushed it to master with some additional debug output and used [deploy] in the commit message.

Would you give it a try and let me know if that works any better than what we have on Windows?

Please try a bunch of code sequences including Ctrl+Shift+1, Alt+Shift+1 and without the shift.

Some keyboards have lowercase letters in the Shift register.

Understood but they should work fine in the Windows test since they differ between upper and lower case.

That seems to working with everything I've thrown it so far (on an English standard Windows keyboard).

Ctrl+Shift+1 results in a working Ctrl+! shortcut (displayed and saved).
Ctrl+Alt+1 results in a working Ctrl+Alt+1 shortcut (displayed and saved).
Alt+Shift+1 results in a working Alt+! shortcut (displayed and saved).
Alt+Shift+G results in Alt+Shift+G that works
Ctrl+Shift+9 results in Ctrl+(
Alt+Ctrl+9 results in Alt+Ctrl+9

All seem to work and are stored/restored from the .ini in working order.

I've tried lots more than that, but nothing seems to messing up that I know of. I'm not a much of a shortcut user, though, so I might have missed something.

Wonderful!

@BeckyEbook would you please try current master on your International keyboard and see if it shows the correct mappings too.

@DiapDelaer - when you get a free moment can you test things are still fully working on Linux as well. Linux still uses our original code so let's hope it just works.

Thanks!