#494 Make shift-lock indicator clickable

[Ark]

First of all, thank you very much for all your hard work, VICE is awesome!

Now for the feature request. My host keyboard configuration does not feature a capslock key. Thus, I cannot tell x64sc to enable or disable shift-lock. The GUI of x64sc features a status bar that includes three indicators, "warp", "pause" and "shift-lock". However, only "warp" and "pause" can be toggled by clicking on the respective indicator area. It would be great if toggling by clicking could be enabled for "shift-lock" as well.

[gpz]

That would create a lot of problems - what if the keyboard DOES have such key and someone clicks the indicator?

Instead, just make yourself a custom keymap and map "shift lock" to some other key (that you don't need in VICE)

(What kind of keyboard is this that doesnt have capslock?)

[Ingo Korb]

Remapping the caps-lock key to something more useful is not that uncommon. Depending on the method the software may see an actual control keycode instead of capslock.

[gpz]

Ah yes, of course - physical key exists, but is mapped to something else :)

[Ark]

(What kind of keyboard is this that doesnt have capslock?)

Japanese keyboard layouts, for example, feature a key that works differently but is located where many other layouts feature a caps lock. In my case, the "caps lock" key has a different purpose.

Instead, just make yourself a custom keymap and map "shift lock" to some other key (that you don't need in VICE)

By "custom keymap" you mean a customized version of one of the gtk3*.vkm files, correct? That might be a way to work around the issue. Thank you for pointing that out.

That would create a lot of problems - what if the keyboard DOES have such key and someone clicks the indicator?

Well, one could turn that argument the other way around: What if I want to enable caps lock on the host without also affecting a VICE running in the background? What if I have multiple VICE instances running and I want to enable shift-lock in one but not the other?

One way to solve that is to decouple the emulator's shift-lock state from the host's caps lock state. Featuring a clickable shift-lock indicator might be one way to accomplish just that.

Also, in my case, since I do not have a caps lock key, it cannot interfere with a clickable shift-lock indicator anyway.

[gpz]

By "custom keymap" you mean a customized version of one of the gtk3*.vkm files, correct?

exactly. Pick the one closest to your actual keyboard, and then make a custom version. (enable "keyboard debugging in status bar" to see what the codes for individual keys are)

[Ark]

I experimented a bit with a customized VICE keymap and … it's complicated.

Apparently, pressing the newly assigned shift-lock-emulating host key (KP_Subtract, by the way, I replaced Caps_Lock 1 7 64 with KP_Subtract 1 7 64) works as advertised and desired: The emulator's internal state is toggled whenever I press the key down.¹ However, whenever the mouse cursor enters or leaves the emulated screen area (this includes the gray padding area) or focus is gained or lost, the emulator's internal state is updated to reflect the host's current caps lock state.

This kind of defeats the purpose of locking, especially in my case where the host's state is always "turned off".

On top of that, I noticed that, at least in my case, enabling caps lock also enables shift-lock, but disabling caps lock does not immediately disable shift-lock. That is, the caps lock key is turned off (along with the indicator in my keyboard) but the shift-lock indicator is on (and I get spades instead of A). Only when leaving the screen area or similar, as described above, shift-lock is turned off again. This feels like a bug to me.

¹: I do not have a real machine at my disposal, but I wonder whether in a real C64, the shift lock is released only after releasing the lock key instead of when pressing it down again. The exact behavior might even depend on the model.

[Ingo Korb]

On a real C64 it's actually a real locking switch that is connected in parallel with the left shift key.

[Ark]

That I remember (along with the sound when it locks into place), thanks. My question is when exactly the line is affected:

• unlocked → pressing key down → line is low/high?
• unlocked → releasing key → line is low (because the key is now locked)
• locked → pressing key down → line is low/high?
• locked → releasing key → line is high (because the key is now not locked anymore, unless you also hold down the normal left shift key)

[gpz]

It is only ever "not pressed" ("high") in the last of your 4 cases (so it behaves different than capslock typically does).

In the emulation it might behave slightly different - and depend on the OS (i am using linux, for me it is disabled directly when capslock is pressed - and on my keyboard the indicator only goes out after releasing the key, so kinda the opposite of what your see :)) - i don't think we can fix this either, the while capslock stuff is crazy hackery and was quite painful to make it work at all, due to the strange (and different) related quirks of all OSs (and iirc macOS didnt give us "release" events at all for capslock, which is why we use "press" only). So what is your OS? :)

please open a bug ticket about that sync issue when changing focus - it is probably not taking the remapping into account

[Ark]

It is only ever "not pressed" ("high") in the last of your 4 cases (so it behaves different than capslock typically does).

Thank you for the clarification.

So what is your OS? :)

Arch Linux.

please open a bug ticket about that sync issue when changing focus - it is probably not taking the remapping into account

Here you are: [bugs:#2134]