Layout customization

[asyncee]

Hello!

Thank you for such a great layout, loving it. I know this question was raised million times, and also i found your comments on simliar questions on reddit. I followed your guide on how to add new layers using those five commits in the repo and got an error:

keymap.o: qmk_firmware/keyboards/crkbd/keymaps/asyncee/keymap.c:53: multiple definition of `keymaps'; manna-harbour_miryoku.o: qmk_firmware/users/manna-harbour_miryoku/manna-harbour_miryoku.c:12: first defined here

I want to customize layout in following way:

1. fill unused keys on my crkbd
2. change home row mods from GACS to CAGS (control alt gui shift) or maybe even to AG only.
3. Maybe move some keys or somehow modify the layout.

I know that you are actively develop layout and implement new features and you have implemented various extensions by specifying environment variables before the build process. That way allows end users to get rid of compatibility issues when compiling new version of keyboard. But are there any way or best practives to customize the layout and avoid compatibility issues for future released versions?

Thanks!

[asyncee]

Also, is https://github.com/manna-harbour/qmk_firmware/commits/miryoku-examples-add-layers/keyboards/crkbd/keymaps/miryoku-examples-add-layers example still valid?

[manna-harbour]

Some of the individual commits are still valid, at least partially, but the overall method of copying into a new directory is only needed if you want to PR upstream to QMK master. Otherwise it'd be much simpler to just edit in place, especially once most changes are supported in just custom_config.h or similar. There will also be an alternative method supported in future to keep all changes in a separate user directory but without needing to copy everything.

[asyncee]

Great. If I will make changes in place then there can be conflicting changes later when I'll pull new features from the repo? (I mean changing files other than custom config).

[manna-harbour]

Great. If I will make changes in place then there can be conflicting changes later when I'll pull new features from the repo? (I mean changing files other than custom config).

There could be as some planned features are added, but I think that'd be easier to deal with than trying to keep a flattened copy in sync as would be required in miryoku-examples-add-layers . Once custom config is supported there will be no conflicts of course.

[manna-harbour]

There have been many recent implementation changes, and there are also some upcoming features to support customisation (which will cover your 3 cases). See #33, #47, #48 for some of them. When things stabilise I'll be adding some customisation documentation. But at the moment, please just ask here as you've done.

1. fill unused keys on my crkbd

To map unused keys you can edit the mapping file. For crkbd that's here. For crkbd you may also need FORCE_LAYOUT (see here).

To map unused keys differently per layer you can define additional mapping macros and use them in the keymap here.

Later you'll be able to do this just by defining the macros in custom_config.h or similar.

2. change home row mods from GACS to CAGS (control alt gui shift) or maybe even to AG only.

QMK has a control / gui swap bootmagic option, see here.

I'm planning on making the mods customisable (see above for the issue).

At the moment you'd have to make the changes manually. If you do it via Miryoku Babel you'd only have to edit one line here. Otherwise you have to edit Base plus all the sub-layers here (for the blocks corresponding to your chosen alternative layout options).

3. Maybe move some keys or somehow modify the layout.

I'm planning on making it easier to substitute custom layers, see above for the issue. For now though you'd have to make changes in the same way as in 2., i.e. either via Miryoku Babel, or in miryoku_alternatives.h.

In general I'd recommend making changes via Miryoku Babel if you're already using emacs, if you want to make the changes to multiple Miryoku implementations, or in the special case of changing the mods (as they are on every layer).

[asyncee]

I achieved following results for Ferris Sweep (34 keys):

• repositioned mod keys
• swapped keys for mouse and fun layers to have access to f-keys instead of mouse controls
• changed thumb combos to produce escape and delete as a result of previous change

I did it this way - completely copied users/manna-harbour_miryoku and applied babel changes there. So now i have flat copy of your user configuration with my custom changes made via Babel.
Then I added a keymap for Ferris Sweep that uses my custom user settings.

And then I got everything working.

But now I have a problem - if I apply same configuration for my crkbd then I will have same user layout, that will cause the board to be completely unsusable because of duplicate functionality of extra keys and home row mods.

So my next question - is there any way to use different babel output (tangled files) per keyboard? I will be happy if you will give me any clues to that.

My current Ferris base layer (used qmk configurator just for visualisation):

Home row mods positions come from user settings.

What I want to achieve on crkbd:

As you can see, shift and control is configured via extra keys using 3x6 layout and now miryoku layout only has alt and gui mods.

Can you help or give any clues to implementation steps i need to do (i will configure everything using babel).

P.S: i tried to include tangled files directly into keymaps but got different errors related to variable redefinitions and/or missing/not matching layout definition.

Thanks!

[manna-harbour]

I think it would be preferable to have the same 34 keys on both. You could have single function duplicates on the crkbd extra keys if they are easier to use, but you could still use the common 34 in an identical way.
Is there a particular reason why you don't want the common 34 keys to be identical? Can you share a link to your repo?

[asyncee]

The reason is the mod taps latency. On Ferris i'm forced to use them as there are no other option but on corne i can avoid using home row mods for two keys. I'm kinda okay with home rows mods but prefer to avoid them if possible. Also corne has two more thumb keys, so i can use almost default miryoku configuration, but on Ferris i'm forced to change thumb keys and thumb key combos (i'm a programmer so i need function layer more often than media/mouse).

Link to repo

[manna-harbour]

Ok, I'd still advise on using the same configuration for both as much as possible.

For home row mods you can increase tapping term, or remove the mod tap from Base and just use the mods on the sub-layers instead. But the visual lag should not be noticeable after a while on choc or on non-linear MX.

The thumb combos should work reliably, but you could also move Fun to the secondary thumb (on both).

But if you prefer, to use a different miryoku_babel directory per keyboard, you could rename the directories per keyboard, and add some ifdefs based on the keyboard name here to chose the appropriate locations. You can use something like #if defined (KEYBOARD_crkbd_rev1) which is defined automatically for each keyboard based on the keyboard directory name, or you could add your own define to the keyboard or community layout level config.h, or define it as an argument when building.

[asyncee]

Great idea, thank you!

[asyncee]

Thanks! I'll try it ASAP.

[asyncee]

For future readers: I decided to support only one keyboard (crkbd) and chose way of customization, which I find the most simple and powerful, see below.

My main points were:

• Map extra keys on my keyboard
• Swap control and gui (i decided to use CAGS howe row mods)
• Have an ability to easily modify layout/layers without much coding, for example, change ' key to ;

Implementation details

1. fork manna-harbour/miryoku_qmk
2. map unused keys using desired layout layouts/community/split_3x6_3/manna-harbour_miryoku/config.h (firmware is compiled with respective FORCE_LAYOUT)
3. Edit Miryoku Babel configuration to swap mods and replace any keys: users/manna-harbour_miryoku/readme.org
4. Compile everything using commands in Makefile I created users/manna-harbour_miryoku/Makefile (see my repo)

These simple steps just enough to accomplish the goal. This way I have full control over keyboard and can merge with upstream changes easily.

See this commit for code example.

P.S.: Miryoku Babel is great.

[manna-harbour]

See #85.