Add a language setting that ensures that the symbols shown matches what is produced when using a OS language other than English

[QEDeD]

Is your feature request related to a problem? Please describe.
As described by @hnrklss in #3 "Currently it is quite confusing to configure a non-US layout where the OS remaps the scancodes to another symbol than the one assumed by Chrysalis."

E.g. if your OS language is set to Danish and you want to make an å, you need to select [ in Chrysalis, which a normal user has no chance of knowing.

Describe the solution you'd like
Under Preferences in Chrysalis, there should be an extra dropdown menu allowing you to pick which OS language you are going to use. According to the language selected in this new menu, the UI and keys would look the same but would change which scancodes are assigned to the keys so that the keys produce the expected output under the set OS language.

Describe alternatives you've considered
Instead of having a separate menu, you could tie the described function together with the 'Language' option which is already in Chrysalis. You can argue that this would be simpler for an end-user, but would allow less flexibility.

[hnrklssn]

I think this is what I had in mind for #256, but phrased much more clearly what the user experience would be like. :)

[QEDeD]

@hnrklssn oh you are absolutely right, I'd tried to look around to see if there was another issue, but failed to find yours. I guess the sensible thing would be to close this issue and perhaps move whatever is useful to #256 :)

[algernon]

Okay, so this is something that has been in the back of my mind for quite some time now. Unfortunately, with the key selector system we have now, this is practically impossible to implement: right now, our key selector and the key database is structured in a way that makes it very impractical for multi-language, multi-layout support. The major problems are things like ; (punctuation) turning into é (letter) when switching to HU-QWERTZ, something our current database model doesn't easily allow. Having é in the punctuation group wouldn't make much sense.

So we need to overhaul both the database, and the key selector. The current plan is to replace the key selector with a 104-key keyboard, which would show the selected OS-side layout, and we'd be able to select keys from there. We'd also have a couple of extra buttons to provide access to keys not on the 104-key layout, such as media keys, layer keys, and all the fancy other stuff Kaleidoscope provides. I'm not yet sure where I'd place these extra things, but thankfully, none of those change with the host-side layout changing.

What does change, however - and this complicates things even further - is that on some layouts, AltGr can turn some keys into other symbols. For example, AltGr+v on HU-QWERTZ is @. We need to be able to represent those too. Sadly, I do not have any idea how to do that in a sane way.

Nevertheless, as a first step, we should have a new key selector, and a way to display keys as the host would display them, as long as no modifiers are involved. We can then iterate from there, and figure out what to do about AltGr and possibly other input methods.

[algernon]

Made some progress, but nothing working to show (yet). In the meantime, let me describe what's about to land in a draft PR very soon:

Database

Instead of having a highly structured database, with different groups for alphas, numerics, punctuation and whatnot, we'd have one big group for keys that can change when switching OS layout, and all other keycodes in various groups like we do now. We'll cut down on the number of groups, however. For example, all layer keys will be in one group: lock, shift, oneshot. DualUse is a bit trickier, because that's not really a group in itself.

This way, we'll be able to swap a small subset of the database to symbols that match the host language and layout. We won't need to care about categorization, or groups, just a simple keycode -> symbol mapping. Since we already have a database of those, I can - and I will - write a script that turns the X11 keycode database into something Chrysalis can use. And then voila, we support a whole lot of layouts and languages!

This subset will also include keycodes with modifiers, so that we can have a HU-QWERTZ layout show á instead of ', and ß instead of AltGr+á (AltGr+' in US-QWERTY). We will also have a flag in the database that tells Chrysalis whether to show shifted or AltGr'd symbols on the keymap. In practice, this means that we'll be able to show (HU-QWERTZ example again) 1 (no modifiers), ' (Shift+1), and ~ (AltGr+1) on the same key. Or 2 and @ on an US-QWERTY layout. Or perhaps even @ and 2, if we ever start supporting the TopsyTurvy plugin.

UI

Instead of a group selector on the side, and a list of keys filling the rest of the selector idea, we'll display a standard 104-key layout there, with a couple of extra buttons on the side to allow access to keys outside of that 104 (such as layer keys, mouse keys, and so on).

The checkboxes under some keys in the selector, which are currently used to augment a key with a modifier, or for setting up dual-use keys will be going away, and will be replaced by a right-click menu on the keymap itself. Said right-click menu will also make it easier to adjust a keys keycode within the same group: for example, if you right-click on a layer key, the menu will allow you to turn it into a oneshot, or change which layer it will point to, without having to move your mouse to the key selector area.

As an example, the current plan is to not have the various types of layer keys available in the selector, just a generic "layer key", or perhaps a list of layer keys (up to the maximum number of layers the firmware supports), but without the ability to select the type of the layer key directly. They will all default to ShiftToLayer(n), and if one wants to change that, they can do that by right clicking the key on the keymap, and selecting the "Layer switch method" (or something along those lines). This does require a bit of mouse movement, but not more than the status quo, and I believe this method is simpler. It reduces the amount of groups, and moves a lot of functionality away from the key selector, into the keymap itself.

Another goal, apart from reducing the number of groups, and making it easier to support layouts other than US-QWERTY, is to make it easier to work with the keymap directly, without having to move the mouse to the key selector. Mousing back and forth is a bit annoying.

Eventually, I'd like to be able to drag keys within the keymap. This will allow us to set up one mouse key, drag it onto a few other keys, and then right-click those to change to another mouse key. I feel this is more convenient than going to the selector all the time. But this is a longer-term idea.

[eloyesp]

I would like to add my two cents here, on one hand, instead of building the database from scratch, I think that it should be built upon the xkb database, this way we will have a big database to play with some extra effort at the start, but it will be easier to maintain on the long run.

Also, I think it will be important to store some of that data on EEPROM, using Chrisalis, to make it easy to adapt the keyboard to different hosts. This way we can add some key to toggle the different compatibility layers, example: I install with Chrysalys the ES-lat the ES-es and the EN-US (intl) keyboards layouts on the firmware. After that, when connecting to different hosts, I can toggle those on and of to make my keyboard work the same (cancelling the host configuration). Also, because how the database is built, ES-lat and ES-es do reuse most of the data freeing storage.

Also, building over xkb makes it possible to draw images on Chrysalis of the keyboard (making it simpler to find a key), and printing the layout (to learn it).

[algernon]

A few things changed since my last update here: we're not building manually indeed, but ended up building on top of the Unicode CDLR database instead of XBD (as the former is considerably easier to integrate with Chrysalis).

As for storing some of the data in EEPROM: you can set up multiple layer sets. One set for ES-es and one for EN-us. So the first three layers would be for ES, the second three for EN. The ES layerset would have a key somewhere that moves to the first EN layer, which would have layer switches within the EN set, and a key to move to the first ES set. For example, Layer 0 would be the base ES layer, with layer shifts to L1 and L2. L2 would have a MoveToLayer(L3) (the first EN layer). L3 would have layer shifts to L4 and L5, and L5 would have a MoveToLayer(L0). This is possible to do right now, although a bit cumbersome, and not very space efficient.

I think it would be more practical at this time to have a way to share (and store) layouts, so if you want to switch from ES-lat to EN-US, you'd just fire up Chrysalis, and push your EN-US layout. A bit more effort than a key combo on the keyboard itself, but much more space efficient.

[eloyesp]

As for storing some of the data in EEPROM: you can set up multiple layer sets. One set for ES-es and one for EN-us. So the first three layers would be for ES, the second three for EN. The ES layerset would have a key somewhere that moves to the first EN layer, which would have layer switches within the EN set, and a key to move to the first ES set. For example, Layer 0 would be the base ES layer, with layer shifts to L1 and L2. L2 would have a MoveToLayer(L3) (the first EN layer). L3 would have layer shifts to L4 and L5, and L5 would have a MoveToLayer(L0). This is possible to do right now, although a bit cumbersome, and not very space efficient.

I've already done that duplicate layer monstruosity, and it is just horrible to maintain, but also it is very difficult to build the first time, because the mapping of keys is not easy (as explained on the first post and on #598 ).

---

On the other hand, my idea was to move the complexity out of Chrysalis and move it to Kaleidoscope, adding the concept of a composition layer, that is a layer that sits behind the rest of the layers and translate codes to match the OS expectation.

What does I mean with a composition layer: On Chrysalis I've configured the dash ("-") on a key, but as I've enabled the composition layer for the Spanish layout, so Kaleidoscope will translate that dash on a ("/") and will send that to the OS, if the OS is set to Spanish, it will translate back to the "-", so I got what I expect.

There are three layers and two composition layers

For this to work, we need:

On the Kaleidoscope side: a default plugin to handle composition layers capable of setting a default, enable and disable them on runtime (the same LockLayer key could work) and a way to load those using focus.

On the Chrisalys side: a message explaining that Kaleidoscope does expect your keyboard layout to be exactly an US layout, and a page to add or remove composition layers (that could explain what they do), select a default one and mapping keys to lock (toggle) them.

---

The advantage of this approach is that it will work for people not using Chrysalis, it minimize the required changes on the Chrysalis side (as most of the Chrysalis interface can still believe that everyone on earth is using an English keyboard).

Does it makes sense @algernon?

[eloyesp]

I think that there is a missing reference to #591 that is addressing in part this issue, so I will mention it here.

[algernon]

With the new Editor, this - the original request at least - is fixed both on master and in the latest release.

@eloyesp Can you open a separate issue about your idea?

[aspiers]

Maybe I'm misunderstanding but I don't get how this is fixed. I use a UK layout, in which @ and " are swapped from where they would be in the standard US layout, i.e. Shift+2 and Shift+'. But if I select either of these keys and click the Shift modifier, Chrysalis shows the US key not the UK one. And if #611 was fixed then it would show the US versions of the Shifted symbols even without having to click on the Shift modifier.

[hnrklssn]

I agree with Aspiers. While keys without modifiers seem to display correctly (great work, Algernon!), shift modified keys don't. So e.g. the + key is now displayed as + when I select a Swedish layout, but if I select shift-+, it shows _, while it should be showing ?.

On a side note, I also found the position of keyboard layout selector confusing, as it is under a collapsed menu in the key selection pane. But I would want to display the correct layout before I decide to change a key mapping: otherwise, how would I know which ones to change? With the current position I get the feeling that the selection is on a per-key basis, since it's under the key selection menu for a single key, but it's actually keyboard wide (which is good btw, the layout selector placement just indicates otherwise).

[stevep99]

Would also echo what aspiers said - this doesn't appear to be fixed.
For example, with a UK keyboard, Chrysalis renders @ for shift-2, but what is actually produced is "

[algernon]

Reopening this, so we can figure out what's happening. I'll follow up a bit later with my findings.

[algernon]

Okay, I finally managed to understand the issue! Apologies, I didn't read the bug-report correctly the first time, and was trying to reproduce the firmware producing wrong input. But that's not the case, it's a display issue! I think I know how to fix that.

[algernon]

This should be fixed on master now, and the snapshot release is building. Once that's built, can any of you take it for a spin, and verify it works as expected?

I know it will not work for stuff like AltGr+2, which should be ² on an UK layout, as far as I can tell, because the CLDR keyboard layout description we use does not have those overrides. We use the windows variants. Interestingly, the Linux variant has the altgr modified symbols too.

[thoni56]

Thanks. It shows the correct glyphs for me in now (0.8.7-snapshot.82). Much easier to work with in Swedish layouts ;-)

[eloyesp]

It seems to work fine, just wanted to mention that AltGr modified keys do not work even on Linux.

But let me explain it better:

To type the ] character on the Spanish keyboard, you need to type: AltGr + "+", but on Chrysalis, it is shown as "AltGr+]"... why? because the key "+" is "]" on the English keyboard...

So it fall back to the English layout when you add the modifier, when you touch the "AltGr" slide, the key "+" becomes "AltGr+]".

-

-

It would be nice to have ] there, but it is enough having it read "AltGr++" (or even better have "AltGr++"="]")

[algernon]

Showing it as ] won't be doable, not unless we fork the CLDR database we use for international layouts. The CLDR layout we use for Chrysalis does not have altgr stuff for most layouts, sadly.

AltGr + + is something I can do, though. Will look into it.