UX: Default Alt shortcuts interfere with some keyboard layouts

[szymonlopaciuk]

Description

The mainstream keyboard layout in Poland, so-called "Polish Programmer's", relies on combinations Alt/Option+Letter for letters with diacritics. While this is not common in the world in general, a quick Google yields that there seem to be other countries using this layout approach.

Defaults in Sigil override these combinations for its own shortcuts which is really annoying as it makes it impossible to type words in my language. Moreover, some of those combinations can execute potentially destructive actions (see example below), and it is difficult to have to pay attention to something so automatic as typing.

After looking I noticed the possibility to change these in the settings, which is good. However, not after accidentally deleting some words without immediately realising what had happened. (I have decided to write this, as I am currently reading the book and keep finding odd mistakes I just didn't know I introduced!)

Example

With the "Polish Programmer's" keyboard layout press the combination Alt+a. The action executed is "Search > Replace All". Instead, the expected output is the letter "ą".

Suggestion

Change the default keyboard shortcut settings (are they widely used?). No other program I have used uses Alt+Letter combination for shortcuts.

(I could submit a PR myself, but I don't want to put in the effort to ruin someone's workflow; equally, I think it's a really annoying little problem.)

[kevinhendricks]

And removing them will break long-time users workflows and will cause other problems. Sigil literally has used these default keyboard shortcuts for over a decade.

After starting up Sigil, use Sigil Preferences to change any and all key sequences once, and they will be saved thereafter. You will not have to deal with them again.

Once you have successfully saved your shortcut preferences, remember to back-up your ini file so you have a known good version in case of any ini corruption.

Or submit a bug report to Qt about its inability to detect your keyboard layout.

[kevinhendricks]

We would consider a PR that leaves the shortcut defaults as they are now unless a specific set of "programmer" keyboard layouts or an international keyboard is detected and supplying a second set.

Removing them for everyone after its long history of use is simply not an option.

[szymonlopaciuk]

Fair enough! I literally got annoyed as this is the way I've been typing since I was a child and never encountered a problem like this before.

We would consider a PR that leaves the shortcut defaults as they are now unless a specific set of "programmer" keyboard layouts or an international keyboard is detected and supplying a second set.

If I have time I can look into this, but realistically I don't know any Qt and this would probably be a bigger undertaking, so don't know when that could be. I may investigate if it's something that Qt should be doing and isn't as well.

Thanks for your responses though! You can close this I guess, I'll leave that to you.

[szymonlopaciuk]

Thinking about this some more, I don't know if there is a good way of salvaging this. Detecting a keyboard layout or locale will only get you so far. E.g., at least on Mac, pretty much every Alt+Letter combo in pretty much every keyboard layout produces a printable character. There is no way of reliably telling if that is an important symbol or not, and some people might use weird characters others don't. (Apparently, French does this for "{".)

Then there is a problem of when you'd run this check. First start-up? Every time a combination is pressed unless explicitly overridden and not default? The layout is dynamically changeable after all...

I don't think there is a way out here. I will let it go unless you have some suggestions. I'm just in disbelief that nobody complained about this before :)

(The name is "Programmer's" but it is the layout used in Poland by 99% of typing people.)

[kevinhendricks]

@BeckyDTP,

As an international keyboard user, did you say recent Qt versions had a keyboard driver fix on Windows that is related to using right vs left alt keys on intl keyboards? I seem to remember you pointing me at something once but I can not find it now.

For your intl users, do we need to supply and install an intl sigil.ini file to properly prevent these types of issues for users?

Any thoughts on this particular issue?

Thanks

[BeckyDTP]

Issue #474 ?

[kevinhendricks]

Yes, that is it. Thanks!

My only other idea to deal with this issue is to split the keyboard shortcuts out of the main sigil.ini file into its own ini file, and install them with language code chars in their filenames (much like translation files work now).

I wanted your opinion on the need for and appropriateness of this idea or does what you posted previously in that issue:

Problem partially can be solved by run sigil with parameters:
Sigil.exe -platform windows:altgr

This does not fix the problem with assigning shortcuts, but AltGr+something, e.g. when editing the code, inserts the correct diacritics, and does not call the Sigil functions that are assigned to the Ctrl+Alt+something keyboard shortcuts.
Maybe it's even worth adding to the documentation?

As for the shortcuts problem, it is possible that in Qt 5.12[.10] it was fixed by this patch:
https://codereview.qt-project.org/c/qt/qtwebengine/+/306722
Unfortunately, I have no way to check it.
(Let me remind you that this problem only affects international keyboards on Windows.)

if we backport that change from 5.12.10 back to our Qt 5.12.9 version) and users launch Sigil with that altgr parameter, will that make this idea unnecessary?

[BeckyDTP]

In fact, as soon as I found this parameter, I wrote it on the Sigil launch icon and forgot about it. I adjusted the keyboard shortcuts to my needs anyway, and changed the conflicting ones much earlier to different ones.
I prefer to run many shortcuts (for Clips) with Ctrl + left Alt + 1… 9, so adding a parameter is a simple solution.

Got an international keyboard and a shortcut doesn't work?
Let it add a parameter.

For my part, I could suggest adding this to the documentation.

---

I am building a Sigil on 5.12.9 and the paramter is needed.

If DiapDealer could prepare a special patched version of Qt for Windows, which correctly out of the box handles AltGr correctly, maybe the parameter will not be needed and everyone using the international keyboard will be satisfied.

[szymonlopaciuk]

@kevinhendricks, I probably should have mentioned in the issue that for me this problem appears on a mac, which as far as I am aware does not differentiate between left and right alt.

My only other idea to deal with this issue is to split the keyboard shortcuts out of the main sigil.ini file into its own ini file, and install them with language code chars in their filenames (much like translation files work now).

This would sound like a sweet solution for anyone who might stumble on this in the future.

[BeckyDTP]

Oh, I figured it was Windows. I didn't notice the "Option" key you mentioned.

Splitting a fragment with shortcuts into a separate ini file should not be a problem or too much prejudice to backward compatibility for the sigil.ini file.

If we could add the ability to import/export a configuration with a keyboard layout it would be great, but is it necessary to create a layout for each language, keyboard layout? After all, two main settings are enough – the default shortcuts and the shortcuts reduced (without potentially conflicting shortcuts).

[kevinhendricks]

On macOS, the old rules were:

left alt = option and
altgr was option + control

What happens on your macOS machine when using option+control to represent the altgr? Does it make the default keyboard shortcyt go or does it allow you to compose characters?

[kevinhendricks]

Sigil could look for the standalone shortcut.ini first and if so load the key settings from there otherwise load them from sigil.ini. But then always save any changes to the shortcut.ini.

Could we get away with just two possible default shortcut.ini files then: shortcut_us.ini and shortcut_intl.ini?

[BeckyDTP]

The idea looks OK to me.
Does @szymonlopaciuk agree that this should be enough?

If the (new) user encounters conflicting shortcuts - he will load the default layout for the international keyboard and can adapt it to his needs, because the "local" file with shortcuts will always be called shortcut.ini.

[szymonlopaciuk]

What happens on your macOS machine when using option+control to represent the altgr? Does it make the default keyboard shortcyt go or does it allow you to compose characters?

I'm not sure I understand. In general, either Option produces characters, e.g. option+a = ą no matter if it's right or left. So, macOS does not rely on AltGr (or Option+Control) for character output, at least on in the layouts I've seen. In Sigil however, this does not happen, and either Option executes a shortcut. If this way of inputting AltGr is a thing, then it means that the expected behaviours of Alt and AltGr would have to be mirrored between Windows and Mac to accomplish what we need.

Could we get away with just two possible default shortcut.ini files then: shortcut_us.ini and shortcut_intl.ini?

Does @szymonlopaciuk agree that this should be enough?

Sounds good!

[matkoniecz]

Another idea is to have warning window

Unfortunately it seems that you use keyboard layout incompatible with default Sigil shortcuts, typing using alt will not work properly what will break for example typing Polish words

{use alternative shortcut preset button} {configure shortcuts button} [ ] never show this message again checkbox

Magical changes to shortcuts will in turn confuse any Polish users looking for help/instructions

[dougmassay]

Please stop bumping old closed issues. Thank you.

[matkoniecz]

This issue is not closed.

[dougmassay]

My mistake. Although In my mind, it should be. We did extensive work to address altgr and international keyboard shortcut issues since this thread was last commented on.