Possible bug?

[KevinH]

Originally Posted by BeckyEbook

The enabled checkbox should fix issue 580.

But only for Windows users right? The op for that issue was seeing the problem on a mac and none of this would help.

[BeckyEbook]

Exactly. I just noticed this and edited my post.

[KevinH]

It must be late your time. I will apply these changes and push to master.

[KevinH]

Okay pushed BeckyEbook's patches to master (with the restart changes and ui changes as well). I tested them on macOS with no issues.

I set [deploy] so that we will get test builds for Windows users with intl keyboards with altgr to play with.

Thanks BeckyEbook!

[KevinH]

So all we need now is a few Windows users who have international keyboards with a real AltGr key to volunteer to help test if this works for their specific keyboard layouts.

If anyone is interested in helping us test this please pm DiapDealer or KevinH here on MR and we can pm you back with a link to the test build.

Any takers?

[DiapDealer]

Everything seems to be fine on Linux. I'll have to take others' word for it that it's working as intended on Windows (with international keyboards). I don't really understand what's expected to work where (and the right Alt key interferes with my Virtual box "Host" key shortcut whenever I enable the altgr setting on an international keyboard layout) on a VM.

The setting seems to have no effect on a standard English keyboard (with a standard English Windows keyboard profile), so that's good (I think).

@Becky: Are you creating shortcuts using the AltGr key in Sigil with this setting? Or is the purpose of properly detecting the AltGr key so that it can still be used without triggering Sigil shortcuts?

If I try to create a Sigil shortcut using the right Alt key (with a Windows international keyboard profile active and the altgr setting set to true), I get a non-working shortcut (and often unicode encoded stuff like \xac written to the Sigil.ini file)

[BeckyEbook]

DiapDealer: This is the purpose of properly detecting the AltGr key so that it can still be used without triggering Sigil shortcuts.

Users of international keyboards were disadvantaged in such a way that Sigil's hotkeys overwritten characters that are obtained from AltGr. For example, in the default layout of the German language, to get the @ sign press AltGr+q. If this shortcut had been "seized" by Sigil, the user would not be able to type "@". After enabling the checkbox and restarting it will be possible.

As for the weird characters in sigil.ini, it's always been the case, but users should not select conflicting keyboard shortcuts.

I have already mentioned in this thread that I personally do not like it, because after pressing Ctrl+Alt+E on my Polish keyboard layout, I would prefer to see just such a notation, and I see Ctrl+Alt+Ę and in sigil.ini it is written as Ctrl+Alt+\x118.
In the German layout in the Shortcuts window, we will see Ctrl+Alt+€, and in sigil.ini it will be Ctrl+Alt+\x20ac

Such shortcuts are completely useless because they don't work. If there was [input box "Shortcuts"], however, Ctrl+Alt+E appeared, it would all work on the Polish[*] system, German[**], and English.
[*] AltGr+E=Ę (or rather ę, because Shortcuts displays uppercase, but normally it would be a diacritic in a minuscule)
Ctrl+left Alt+E = keyboard shortcut assigned in Sigil

[**] AltGr+E=€
Ctrl+left Alt+E = keyboard shortcut assigned in Sigil

Maybe I think otherwise, but I have the impression that for standard keyboards it would not matter because AltGr is not used there, but for international keyboards layouts it would be concrete progress and no records /xNNN in sigil.ini

But it may not be possible to do it, because since in the current thread the problem was related to the Shift key (and I have the impression that it has been resolved) then this problem is quite different.

[DiapDealer]

Got it. I think I understand, now Thank you for explaining so thoroughly.

[RbnJrg]

After downloading the last beta, I did some tests.

First at all, my keyboard layout it can be seen in this post:

https://www.mobileread.com/forums/sh...6&postcount=26

I made tests with AltGr disabled and AltGr enabled. I also tested Ctrl + Shift combinations in both events. These are my results:

With AltGr disabled:

1. Ctrl + Shift + 6 is not right detected. It detects "Ctrl + ^" when it should detect "Ctrl + &"
   
2. Ctrl + Shift + ^ is not detected at all.
   
3. Ctrl + Shift + 0 is not detected at all. It should detect Ctrl + = but it doesn't.
   
4. "AltGr + 1" is detected as "Ctrl + Alt + |" but doesn't work. Nor "AltGr + 1" nor "Ctrl + Alt + 1". The same happens with all AltGr combinations; the chars are right detected but don't work.

With AltGr enabled:

1. Regarding the Ctrl+Shift combinations, the same issues that in the case with AltGr disabled.
2. "AltGr + 1" is detected as "|" but as shortcut, is not working (and it shouldn't because a char can't be a shortcut)
3. With AltGr enabled, in the Shortcut field is written only the respective character, but not something like "AltGr + |" or "AltGr + @" or "AltGr + #", etc., etc.

Conclusions: with my keyboard, the Ctrl + Shift combinations work fine, except in the case of Ctrl + Shift + 6, Ctrl + Shift + 0 and Ctrl + Shift + ^.
With AltGr disabled, the combinations are right detected, but don't work. With AltGr enabled, no combinations are detected, only the respective character obtained by AltGr + Key.

[KevinH]

Hmm, back to the drawing board I fear.

I will code up the approach BeckyEbook also found that uses a Windows call to get the base key and we can test that to see if it has the same issues.

[KevinH]

@RbnJrg
Would you please try this for me and post the output here:

1. Set the SIGIL_DEBUG_LOGFILE environment variable to a path to a log file on your Desktop someplace. Sigil will create the file when launched and write some debug output to it.

2. Fire up Sigil, and run your failing Ctrl+Shift combinations (with AltGR disabled)

Please try:

Ctrl + Shift + 6
Ctrl + Shift + ^
Ctrl + Shift + 0

in the KeyboardShortcutsWidgets Preferences Dialog then close out of Sigil.

3. The debug log file you specified should be created on your Desktop (if you set that path and name). It is just a text file. Please copy and paste its contents into a post in this thread surrounded by CODE square bracket tags.

Thanks!

[RbnJrg]

Originally Posted by KevinH

@RbnJrg
Would you please try this for me and post the output here:

1. Set the SIGIL_DEBUG_LOGFILE environment variable to a path to a log file on your Desktop someplace.

How do I set the SIGIL_DEBUG_LOGFILE variable? Where must I search for it?

I forgot to mention that with AltGr enabled, the combinations "Ctrl + AltGr + Key" don't work either; in the Shortcut field only appears the Key.

[KevinH]

I googled how to do that for Windows and found this:

https://www.architectryan.com/2018/0...on-windows-10/

[DiapDealer]

Type 'env' in the Windows 10 search bar and then click on the "" Edit the system environment variables" link that should show up in the right-hand pane.

Click the "Environment Variables" button in the bottom right portion of the resulting System Properties dialog box.

Click the "New" button in the top (User variables) section.

Put SIGIL_DEBUG_LOGFILE in the top variable name text-box

Put a full file path you have write permissions to in the bottom value text box. I suggest:

C:\users\<your user name>\Desktop\sigil-log.txt

Replace <your user name> appropriately, of course, and surround with quotes if your user name has spaces.

Click the OK button
Click the OK button on the environment variables dialog
Click the OK button on the System Properties dialog

Next time you Start Sigil, the sigil-log.txt file should be created on your desktop.

It will accumulate, so feel free to delete the file (it will be recreated) if it get polluted with a lot of extra stuff.

Delete (or slightly rename) the SIGIL_DEBUG_LOGFILE when done. I leave it there, spelled slightly incorrectly so I can easily turn logging back on/off.

[DiapDealer]

Hey, It's good to know my method has proponents (who add screen shots).