Find the friction when using tmk_core

[wobbol]

Make a PR about it.

[squarefrog]

Take a look at what I've done here: https://github.com/squarefrog/tmk_ergodox

I think this is a decent route forward with tmk - you separate the core from the cub fork.

The other option if you want to stick with the cub style fork is to port to https://github.com/jackhumbert/qmk_firmware

That branch seems much more responsive for merging in keyboard specific code.

Personally, I find once you've got a setup that works well, stick with it. The advantage of the original tmk is it is mature and stable. QMK seems a bit more bleeding edge.

I hope that helps?

[squarefrog]

Sorry I've just looked at the commits, and found you've already done that :)

[wobbol]

It's your work in those commits :P

I like the stability of tmk. At the same time, I like what QMK and friends are doing with the KLL, but would rather have an off-line, compile-time config. Also, without having a hardware backstop, like a pushbutton, to keep the usb interface from pushing firmware to my keyboard, I feel uncomfortable.

From what I see, the keyboard community has moved on past the original hardware design of the ergodox, but they still call the new un-compatible designs "ergodox". input.club is the probably the biggest offender by listing their "ErgoDox Infinity" as "ErgoDox" in the config drop down. I nearly hear "I am not going to support such an old, busted design that we don't sell here." QMK seems a lot better, but the ErgoDox EZ website they link to does not clearly spell what micro-controller they use. I don't like to hunt for basic information.

I don't want the users to fight the software. I would like to make it easy for them to get a foothold without resorting to bitmap gui. eg. man pages available, tar.gz packages, a PKGBUILD, an ebuild. If I were to do this, I would definitely find CI that I am comfortable with to generate and submit these things on git tag release.

All that aside, I think having a KLL -> keyboard_whatever.c available from someone would be a great first step to reducing user friction. I think a libcurses interface or a nvim plugin would be a place I would start.

[squarefrog]

Yeah I think gui or KLL translator is the easiest win for the end user. Part of what made the ErgoDox originally accessible was the mass drop config tool.

My first layout took a while to figure out, as my C skills were rusty, so if someone isn't a programmer then it's definitely a big obstacle to overcome.

Personally, I find QMK too busy. Pulling in the repo, with hundreds of layouts for keyboards I don't own seems rediculous to me, which is why I like this simple tmk_core based approach better for me.

As for CI, I don't see why something like Travis wouldn't work, although I've only used it for iOS. It's been a while since I set up the tooling on a new machine so can't remember what exactly you need for compilation.

[wobbol]

Maybe a .net core gui would be the easiest way to get multiplatform without extra deps. Also, because C# seems kinda nice.

When I started, it seemed pretty easy to open a config file and change the keyboard array thing. My problem was not knowing what I wanted where and the lack of visual cues didn't help.

I think QMK is the thing that many people wanted tmk to be, a keyboard software repository. I'm glad tmk_core is available, it truly simplifies the repo layout. At the cost of making it harder to submit changes upstream.

There are a million CI choices, whoever decides to add it first should choose which I think.

Before I forget, feel free to tinker with whatever you like. I am going to continue working on the docs for a while until I feel like the sections flow in the order a new user needs them in.

[wobbol]

This is going to need lots of work. Ideally, a talk with the tmk_keyboard team would be needed before this can really be addressed. If this talk happens, documents concerning tmk_keyboard's direction should be submitted to tmk_keyboard.

[wobbol]

as long as the code is simple and well documented, this won't be a problem.