Qmk_firmware: Keymap_nordic needs to be split

[fredizzimo]

I'm currently building my keyboard layout in QMK, using the keymap_nordic helper.

However, it appears like it's built according to the Danish keyboard layout. The problem with that is that there's not really any generic Nordic keyboard layout, each country (except Sweden and Finland), has a slightly different variant of it.

Furthermore there is at least one bug in the Danish layout. The NO_QUO, refers to the dead key which produces a diaeresis, mostly so that they can type the Swedish ä and ö, which would be quite common, since they are neighbor countries. NO_QUO2 on the other hand refers to the standard quotation mark (").

The Norwegian layout already has it's own version, but the other layouts need their own variations.

So there would need to be

• Icelandic - this is actually very different from the current Nordic one
• Norwegian - already exists, but should probably be extended with the Sámi variant
• Danish/Faroese- the current Nordic, if we add, Đ we get Faroese support as well
• Finnish / Swedish - should use the extended Finish Multilingual version, rather than the standard one, as it only adds buttons and don't remove them. And then we also don't need the Sámi variants.
• Greenlandic - Again quite different,

So the Norwegian, Danish and Finish could share the same base, the others would probably be better implemented from scratch.

I can implement at least the Finnish/Swedish variant, but my question is how it should be structured. Should we use different files for each variant, or use the same file, but different prefixes. For example FI_ for Finnish layout?

I think using one file would make much sense, but the problem with that is of course that NO for Nordic and Norwegian clashes with each other. Furthermore, we probably have to assume that both Nordic and Norwegian are "locked" and can't be changed, not even the quote bug that I described above can't be fixed, otherwise we risk breaking user keymaps (those that are not part of the repository, the ones that are can be refactored).

So the safest thing to do, would be to deprecate the Nordic one, and use separate files for the others. We can also fix the Danish variant this way.

Another thing that I would like to see, is that we use the html names for the characters, so aelig, rather than NO_AE for example. Because not all the characters have a short name like that for example å (aring). But that naming would break the existing Norwegian keymap. So what should we do about that? Should we leave Norwegian as it is, and apply html naming for the rest?

[fredizzimo]

Just a small correction and addition

I don't know how I didn't think of it, but there's a short form for å, and that's aa. However I don't have any idea where to find the replacement forms for all the characters in all Nordic languages, so it's probably still better to use html names. That also makes it a lot easier to find which code you should use.

I also think that we could add the real characters as comments, since most users viewing those, would probably be able to see them correctly as either windows code page 1252 or ISO 8859-1 (latin 1).

[fredizzimo]

I found another problem with the Nordic keymap

Shift + 4 is called NO_BULLT, which I assume stands for bullet. However the character typed is actually ¤, which is the generic currency symbol.

The French keymap also has the same problem.

As a side-note, that's probably the least used symbol on my keyboard, as I have never used it (if you don't count this message), and I don't think I ever seen it used anywhere either, with the exception of texts describing it's origin. And on top of that the $ symbol is on the same key, but you have to use the much harder to press alt-gr + 4 to generate it.

[jackhumbert]

Ah, yeah - I know very little about other keymaps. I was hoping others would come along to tweak them :)

I think unless the language/layout is for exactly the same language, it should have a different prefix and a different file. I think there's some standard for 2 letter language prefixes, but I'm not sure what those are.

Depreciating sounds appropriate. I like the html names - we could do those as aliases to not break things.

NO_BULLT

I think I just assumed that was a bullet - ignorant american here :)

One idea would be to use a lowercase prefix to re-do all of them, eg fi_ARING. I'm not sure this is the best idea though, and probably goes against most C standards.

[fredizzimo]

Since, the Norwegian keymap is the only problematic one, and has already been fixed, and has the right prefix (NO). I think we can just add new h files for the rest of the keymaps. So in order to use the new one, you just include the country map instead of the nordic one, then you will get compile errors because the NO_ variants are no longer defined. If the user does nothing, it works exactly as before.

For the Norwegian map, we have two options, either fix it and the keyboards using it . Or deprecate the file. It would be easy enough to fix the one keymap that is part of QMK, but we don't know about other keymaps. I guess it would be quite safe to do though, as I doubt there's a lot of users, using it.

To deprecate we could add "keymap_norway2.h" and add a waring to keymap_norway.h like this #warning "keymap_norway.h is deprecated, please include keymap_norway2.h, and fix your keymap".

Microsoft has a good online viewer for keyboard layouts. Which should help making these kinds of files.

[fredizzimo]

I just thought about doing it another way.

It would be great if we used a common prefix for all country specific keymaps. That way, changing from one OS layout to another would just be a matter of changing the include file.

In that case, we just deprecate all old prefixes, and to migrate, you change it to the new one. If a key doesn't exist in a certain map, you get a compilation error.

If we do it like this, we probably need to have different names for dead keys, since some OS maps might(but I doubt it) have both a dead and normal key for the same character.

[lindhe]

I've started tinkering with this (specifically for Swedish), and I very much agree that it would be awfully convenient to have them share the prefix, so one could just swap the header file to get another key map. For my own purposes, I'll go with the NO_ prefix for now, but I'll not make a pull request before we are on the same page here.

[lindhe]

I have a branch for Swedish layouts. I don't think it makes sense merging it to master before we have settled on a standard for the language support, but it's good to have it available in the mean time.

Can I make a Pull Request to a non-existing branch? It's better to have it in your repo too, so it's easier to find...

[eyJhb]

I have a danish keymap, that almost functions. But there are some keys like ^, ` and tilde, that does not work as expected as for US layouts, since they require you to type a space AFTER having pressed the correct combo.

You can check it out here - https://github.com/eyJhb/qmk_firmware/blob/master/quantum/keymap_extras/keymap_danish.h
It has only been used for personal use, so it is quite rough...

Sorry for the grave digging, but we really need to split the nordic/norwegian up, and have swedish, danish and norwegian (I see we already have norwegian and swedish, so with minor work we could add danish!)

EDIT: As far as I can see, this could be closed?

[nickoe]

I would like to see a danish configuration too.

[eyJhb]

@nickoe if people are interested, I will do some cleanup and make a PR.
I'm also available for discussion on Freenode IRC :)

[lindhe]

@eyJhb Double pressing the key will produce the correct character. To me, that's good enough a work-around.

[eyJhb]

@lindhe well, reducing key presses is a common goal, I would say.
But my workaround is just setting up the most ugly macro I have ever seen, that adds a space after pressing the keys, and it works great (but ugly)!

[stale[bot]]

This issue has been automatically marked as resolved because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.