Issue loading locally from directory

[billyjacoby]

First off, I absolutely love this project and I'm planning on doing everything I can to help contribute to it!

I'm working on getting everything running locally but for some reason when I clone my zmk-config repo into the root of the project directory, it seems that the app can't load my existing keymap.

When I select 'Local' in the top right, it shows the proper layout for my keyboard, but none of the keycodes are filled in.

Perhaps the strangest part is that when I run this from here everything loads fine.

I'm guessing it's a simple config option I'm overlooking, so feel free to just link me to a doc that I may have missed to get me on my way.

Thanks!

[nickcoutsos]

Hi!

Sorry for the confusion, you haven't done anything wrong on your end. The issue is that the code in this repository is quite old now. Local support has fallen by the wayside as I continued on the GitHub integration and switched to parsing the devicetree source directly so they're a bit incompatible in this way.

Edit: if the ability to use this both locally and online is critical you can re-create your keymap offline, then commit and push the generated keymap.json file and in the hosted editor check the setting to enable legacy keymaps.

[billyjacoby]

Ahhh okay, so it sounds like the best way to dev on this locally is for me to setup my own GH app token and stuff then right?

[nickcoutsos]

Ah... perhaps. I'm not in a good place for collaborating these days. If there's a feature you're looking for I'm open to hearing about it offering some thoughts but I can't promise a lot right now.

[billyjacoby]

No worries, I can totally relate! I’ll poke around and do what I can to get up and going and if i really get stuck i’ll reach out.

Most of the features I’d like to see you’ve already called out in the issues - the first I wanna look at being adding a short description of each of the key behaviors. I’m pretty new to ZMK in general so hopefully this will help me to learn more all around!

[nickcoutsos]

Oh, interesting. I thought I had that already... currently you can hover over keycodes in the selector and a tooltip will display the description text, but somehow the same isn't working for behaviours. I did some work recently to simplify the picker components and allow for more purpose-built versions (e.g., the colour picker for the &rgb_ug RGB_COLOR_HSB binding). It's possible I broke this in that refactor, or else this feature will make it easier to add behaviour descriptions in the first place.

[nickcoutsos]

I had to check again, it turns out I hadn't added descriptions for behaviours at the top-level, just for the "commands" that some of them include. I'll add some myself for a short term fix but at the same time I'm moving toward an approach where I get the base details from the ZMK source directly and layer my own customizations on top.

For example, I've switched my keycodes list over to this so that I can easily keep them up to date with changes in ZMK (not sure if new keycodes are being added since they're coming from the HID spec) without affecting custom definitions that add text/icon glyphs.

I should make another issue to discuss this as it gets a little complicated.

[billyjacoby]

Yeah I was hoping there would be an easy way to parse info from the docs dir of the zmk repo, but after a quick glance I'm not sure how simple that will be. But that's something I'll look into as well!

[nickcoutsos]

That's where I'm looking as well. There's some information to be gleaned from the source, but it isn't the complete picture. I have a script to get a list of the defined behaviors with their bind label and other properties.

For example, I can parse app/dts/bindings/behaviors/zmk,behavior-caps-word.yaml to learn the behavior's compatible property and that it accepts the properties continue-list and mods, but I have to know already what those parameters are for in order to make an editor component that provides the correct values. It would be helpful to have a schema that tells me more, like the fact the the values in mods are supposed to be HID modifiers, maybe even pointing to a location that enumerates them, and that they should be combined using a bitwise OR. I think that specific file is meant for defining the behavior in the context of Zephyr so maybe that isn't the place for these details.