phoscur / oryx-macro-hax Goto Github PK

Catching up here, just wanted to pop in to say thanks for taking the project over!

Following up on gittyeric#7
We need to stop comment out eachothers macros.

I want to refactor

• extract my-macros.ts per user macros/<username> - add feature flags to enable loading multiple macro collections
• move macros.ts into src folder

I can't decide which Oryx Layout to use as a base, because I want layers from multiple sources!

Then, I have something for you, now!
Generated an API Client SDK and created a little CLI prompter to copy layers from other layouts:
https://github.com/Phoscur/oryx-layer-inserter

Best regards,
Phoscur
(shameless self-advertisement)

Feel free to brainstorm what we can achieve by merging the repos, or maybe making use out of the API Client SDK through npm dependency! Follow up on #4:

• Layer Boilerplates: e.g. Bone/Neo(Qwertz) Layers 1-6 + Variants + Extras
• Macro Groups/Prototypes with Key Selection (+automatic modification/maintenance)
• Applied Guide: Like the new Oryx Tour feature, but with the option to copy keys one by one to your own layout

I think I'm failing to update the .env file correctly.

I copied the text in the provided .env.dist file into a new file I named 'process.env', and confirmed that it is a file of type .env. I've updated it with my information, as follows:

USER_NAME="DeepSky8"
LAYOUT_ID="0LXoN"
LAYOUT_FOLDER="moonlander_qwerty-js_source"
LAYOUT_SRC="./layout_src"

--

When I run
npm run get -- 0LXoN

I receive the following update and error:

Downloaded layout "0LXoN" to ./layout_src (from https://oryx.zsa.io/rails/active_storage/blobs/redirect/eyJfcmFpbHMiOnsibWVzc2FnZSI6IkJBaHBBNTAxUUE9PSIsImV4cCI6bnVsbCwicHVyIjoiYmxvYl9pZCJ9fQ==--bb15af0be4346b3ef05dc6d4b34036ec6d80b9ad/moonlander_qwerty-js_0LXoN_Jyz49.zip).

TypeError: The "path" argument must be of type string. Received undefined
at new NodeError (node:internal/errors:400:5)
at validateString (node:internal/validators:163:11)
at join (node:path:429:7)
at C:\Users\Joel\qmk_firmware\ergodox-macro-hax\src\oryx-downloader.ts:53:29

Could you offer some insight what I'm failing to do correctly?

Thanks!

For Windows (but also other operating systems), we will assume that Wally is already preinstalled, it should just be launched and fed with the most recently built firmware.

• add package.json script to launch wally: wally-cli -f <path-to-firmware-file>

Hints:

Remains to be found out what firmware path we give it, currently recommendations are putting it into a parent folder where one manually compiles it. Alternatively, it could be downloaded from the latest action pipeline...

Help from ChatGPT:

I want to import layers from https://github.com/JHoahg/The_NEO_has_landed

There won't be any way to bring this back nicely into Oryx, from [email protected]:

• Allow import & export of layers by JSON serialization through the GraphQL API

I'm afraid we're pretty firmly against this for Oryx for a few reasons. Any form of uploading is really off the table just out of an abundance of caution. We did also consider adding a way to copy layers and keys but ultimately decided against it, as then it would be super easy to copy a bunch of things and end up with an unmanageable layout -- or even to run up against your keyboard's firmware size limit.

Or is there... I'll keep writing back and forth with them a bit more.
And we could still just set them one by one through API or Browser automation...

While #10 should focus on the most used commands, the yet-to-be fully drafted command wizard is going to use the insight from oryx-layer-inserter to guide through macro creation (and copying layers).

Wizard Subcommands

Wizard may automate macros/username.ts creation and append new macros

• list macros with and without expansion
• setup create the macros file
• create macro creation for a specific key -> set-key
• insert copied/blueprint layer (import from layer-inserter)
• save push + download-bin wait for the action pipeline then get the firmware file

I think create needs an adequate representation of the layer to select a specific key. I have to check how much the prompting library changes on this.
(Refactor #8 to use inquirer (+ zod & @molt/command))

Do you have additional ideas? What are your thoughts about this?

Following up on #7 and some experiments in oryx-layer-inserter I created #8 with yargs, prompts & node-persist, this covers a base for better UX, adding more commands & caches, as well as merging the repos.

Combined Commandlist:

• auth get JWT authorization token (manual, only possible to automate as user script)
• data get my layouts list
• open new layout revision (manual, TODO automate?)
• insert (create/copy) layer (#6)
• set-key WIP (#6)
• wizard create username file, prototype macros #11
• get* (download-src) keymap source
• process* keymap expanding macros
• compile*
• flash* (manual, TODO #12)

*unauthorized mode - auth is actually not needed (only layoutID)

The last three commands and potentially essential parts of the wizard cannot be run inside the browser, but they could also generate a browser snippet to set the macro key, for example. I might explore this later, so the layer-inserter will become a playground for tamper monkey scripts.

Automation as console prompts for Node.JS, initial flow:

0. auth - prompt to get the auth token is a messy manual task, description: localStorage.getItem('jwtToken')
1. data - provides layout & layer IDs (a bit slow for many layouts)
2. open - create a new revision, required if the layout is to be modified (insert, set key) - manual for now
3. wizard - guide through macro creation TODO #11
4. get (download-src) - get & unzip the keymap source TODO check open
5. process - apply macros expansion, add stuff to the keymap.c file
6. compile - call qmk locally
7. flash - call or at least open Wally (#12)

Most interesting "everyday" usage flow

0. auth - needs just to be checked, the token is quite long-lived, if it timed out fall back to caches & prompts in "unauthorized" mode
1. wizard - just skip to change a typo in a macro, or add one from a blueprint... #11
2. open - don't, just check that no open revision exists, to be ready to download - recognize unchanged
3. download - only if the layout changed
4. process, compile, flash & data - meanwhile processing update caches

I'd like to implement the fast path first: "new but closed revision found" - download & process - no prompts.
How important is this "unauthorized mode"? Likely depends on the usefulness of the wizard (#11) and the potential selection of new macros from a yet-to-be-created macro and layer library... (#6)

What are your thoughts about this?