⌨️UOptozoraxNomk

Так как QMK слаб, я считаю что надо написать собственную Прекрасную Прошивку Будущего. Я не гарантирую что я буду это писать, но идея витает давно, и просто хочется это сделать. Если я найду в этом огромный источник дофамина, или не огромный источник финансирования (хотя бы 15$ в час), то обязательно займусь им.

На данной странице находится описание того как данная прошивка будет организована и основные идеи к ней. Пишу это, потому что такие обсуждения часто возникают, и просто хочется систематизировать это на одной странице.

Так же тут всё довольно перемешано и не очень структурировано, потому что это страница с набором идей, а не статья.

Название

nomk — Not Only Mechanical Keyboard (No Mechanical Keyboard), аналогично QMK, ZMK и TMK. Такое название одновременно отрицает подходы QMK и ZMK, имея в названии No MK; и одновременно отрицает необходимость иметь механическую клавиатуру, чтобы пользоваться этой прошивкой. Так как программируемыми клавиатурами являются в основном механические, то название хорошо отражает цель поддерживать обычные клавиатуры, будь то ноутбучные или мембранные, софтварным путём.

Название nomk должно писаться всегда с маленьких букв, написание большими буквами недопустимо.

ЯП

Обязательно Rust, потому что этот язык лучше C/C++ (которые обычно предназначены для микроконтроллеров), и вообще лучше любого императивного языка. Плюс у него есть возможность компилироваться под микроконтроллеры. Так же он крайне легко компилируется в принципе (за это низкий «поклон» cargo). Благодаря его фичам можно писать очень высокоуровневые, но при этом быстрые и маленькие программы. Так же Rust позволяет не бояться таких ошибок с Undefined Behaviour, как выход за пределы массива.

Ну и самое главное, у меня есть желание программировать только на этом языке. Я с ним на порядки сильнее, чем при использовании C/C++. Так что с счисто экономической точки зрения куда выгоднее писать на Rust, и пытаться решать (или не решать) его проблемы с компиляцией под микроконтроллеры, чем использовать легкокомпилируемые C/C++, но при этом попасть в ловушку багов за счёт того что это более слабые в выразительности языки.

Фокус

QMK слаб не во всём, а только в фичах, касающихся задания раскладки. Поэтому данную проблему я хочу и способен решить. Но я не способен решить проблемы поддержки Bluetooth и прочие удобства для работы с железом, потому что я не разбираюсь в железе, и тут наверняка напишу полное УГ. Поэтому я фокусируюсь только на раскладкостроении. Я буду скорее стараться свои наработки линковать с QMK/ZMK, чтобы сделать их сильнее, а не буду создавать отдельную прошивку.

Микроконтроллер

Если так будет проще, то я буду фокусироваться только на микроконтроллерах, в которые сможет скомпилироваться Rust, и только на тех, где имеется большое количество флеш-памяти. Я принял такое решение, потому что слабость QMK в том, что он ориентирован на слабые и дешёвые микроконтроллеры на архитектуре AVR, и это крайне сильно его ограничивает.

Одновременно ораска и фираска

Данный фреймворк должен иметь возможность не только запускаться внутри клавиатуры, но ещё и запускаться как программа на любой из ОС: Windows, Linux, Mac (опционально Android, iOS). Благодаря этому можно будет быстро тестировать свою раскладку, обладать бо́льшим набором возможностей (набор юникодных символов, управление окнами без костылей итд), и вообще самое главное — иметь возможность запрограммировать раскладку любой сложности без покупки программируемой клавиатуры. Это очень сильно снизит порог входа в эту область, потому что люди, обладающие стоком, смогут иметь свою раскладку.

Всякие AHK, MSKLC, Enhanced Keyboard работают только на винде. Для линукса надо отдельное решение, для Мака — третье. Из-за чего единственным способом иметь сложную раскладку и не загонять себя в в рамки — это засунуть раскладку в программируемую клавиатуру.

Так же единственной возможность иметь у себя в раскладке слои, аккорды, mod-tap'ы, tap dance — это снова использовать QMK, потому что он единственный в этом достаточно силён, по сравнению с другими программами.

Одновременно драйвер

Слабость любой фираски в том, что она ограничена стандартным протоколом HID, из-за чего клавиатура не может посылать события:

  • Нажать прозвольный юникодный символ, будь то русская буква, «ёлочки», ударение или математический знак.

  • Универсальных кейкодов (для разных ОС) для включения нужного окна.

  • Возможности смотреть какая сейчас программа/ОС запущена, чтобы в зависимости от этого посылать разные хоткеи для разных программ. (например это можно использовать чтобы сделать клавишу, которая везде работает как Enter, а в Discord'е работает как Shift+Enter, а клавиша отправки сообщения везде была Ctrl+Enter, а в Discord'е просто Enter. Таким образом мы можем сделать во всех приложениях такие хоткеи какие удобны нам, и это будет работать везде где нам нужно по умолчанию, на любых компах без импорта настроек клавиатуры.) (или просто можно сделать чтобы в терминале клавиша Copy нажимала Shift+Insert или что там, а во всех остальных программах нажимала Ctrl+C)

Обычно это делается через костыли в настройке ОС и клавиатуры. Так же это очень легко сделать путём использования софтварной программы для переназначения клавиш.

Поэтому программа, которая висит в фоне, должна не только предоставлять возможность запускать свою раскладку, но и должна, если что, слушать клавиатуру через особый протокол, симулируя «драйвер». То есть если клавиатура говорит «включи окно терминала», то обычно это должно быть реализовано в клавиатуре через костыли в виде «нажми Win+2», а если же вдруг клавиатура узнала, что на компе запущен драйвер, то она никакой костыль не нажимает, и просто отправляет «драйверу» это событие, а драйвер через функции ОС открывает окно терминала.

Такая возможность позволит работать клавиатуре одновременно на чужих компьютерах без всякой установки драйверов, и одновременно работать прошивке внутри клавиатуры настолько же хорошо и разнообразно, как и если бы эта раскладка задавалась через софт.

Так же должна быть возможность расширять раскладку клавиатуры через драйвер. Например, это может быть полезно, когда у тебя 10к автозамен, которые тупо никогда не поместятся в клавиатуру, но зато поместятся в оперативную память компьютера.

Ещё этот драйвер нужно сделать так, чтобы он позволял отправлять внутрь клавиатуры информацию о том как надо нарисовать сейчас подсветку. По аналогии с тем как это работает для клавиатур фирмы Corsair, когда они для разных игр могут на подсветке клавиатуры показывать когда тебе наносится урон или тебя хилят.

Или можно через драйвер отправлять информацию на дисплеи Corne.

Ограниченная фираска

Зачем вообще нужно хранить раскладку в клавиатуре? Обычно это единственный случай: когда твоя ОС ещё не запустилась, то есть ты сидишь в BIOS'е и всякое такое. А когда такое происходит, то здесь нужно только одно: иметь возможность нажимать английские символы и стандартные кейкоды.

Значит можно сделать так, чтобы раскладка кастрировалась только до нажатия обычных вещей, удалялось всё связанное с другими языками, юникодом, управлением окнами, и это в таком компактном формате заливалось в клавиатуру. Тогда это позволяет хранить в клавиатуре минимально кода, и, наверное, он даже сможет поместиться на AVR микроконтроллеры.

А как только клавиатура видит что драйвер nomk включён, сразу переключалась только на него, со всеми сопутствующими фичами.

Одновременно Typing Statistics

Есть такая шикарная программа под названием Typing Statistics, но к сожалению она есть только для Windows и не учитывает возможность пользоваться нестандартной клавиатурой.

Раз будет единый софт для работы с раскладками и отлавливанием нажатий, то можно будет сделать, чтобы он ещё записывал в другую программу все нажатия, и позволял делать всё что есть в TS: визуализация нажатий, подсчёт скоростей брутто итд.

Дополнительно можно встроить функционал кейлоггера, который будет записывать все нажатия. На основе него можно сделать автоматически подсчёт всех би-, три-, n-грамм. Можно будет сделать подсчёт тепловой карты использования клавиатуры.

Ещё на основании этого кейлоггера можно будет сделать софт, который будет отслеживать когда зажимаются хоткеи, и соответственно считать частотность хоткеев. Это затем можно использовать при переносе хоткеев в слои.

Я уже делал подобное, создавая софт heatmap, но он довольно слаб.

Так же через конфиги раскладки можно будет указывать какой палец какую клавишу нажимает, благодаря чему визуализация в таком TS будет более корректной, и ориентированной не только на сток.

Формат программы

Для ОС-программы/драйвера данный фреймворк должен быть portable экзешником без зависимостей, который запускается без всяких установок. Соответственно он сможет быть запущен на компьютере без прав администратора, либо его можно таскать с собой на флешке. Так же в таком формате его гораздо проще использовать и управлять им.

Чтобы эта программа автоматически запускалась при старте системы можно добавить фичу, при которой запуск её с соответствующим флагом помещает её в автозапуск. Запуск с другим флагом удаляет из автозапуска.

Хочешь удалить программу — удаляешь экзешник, и её больше не существует.

В виде программы данный фреймворк должен отлавливать все нажатия клавиатуры и переназначать их в другие в соответствии с раскладкой.

Для фираски должно быть фираской, тут всё просто.

Возможности для клавиатурного тренажёра

Хотелось, чтобы в раскладке/клавиатуре можно было включить режим клавиатурного тренажёра, при котором нажатия модификаторов посылаются в виде текста, чтобы можно было тренироваться нажимать хоткеи на скорость.

Возможность не прошивать раскладку в клавиатуру

Если у нас есть возможность работать с таким «драйвером», зачем тогда вообще нужно иметь раскладку внутри клавиатуры? Можно заранее настроить эту программу на рабочем и домашнем компе и вообще не париться.

Действительно. В таком случае можно сделать следующее: в клавиатуру прошивается максимально легковесная прошивка, которая только и делает, что работает через этот драйвер. Таким образом можно даже использовать слабые микроконтроллеры на архитектуре AVR, которые имеют всего 32кб флеш-памяти.

Ещё можно сделать, чтобы внутри клавиатуры был зашит uuid текущей раскладки, которая хранится на gist.github.com, и тогда минимальная прошивка может просто говорить этот uuid, а программа будет его автоматически скачивать и интерпретировать. Тогда даже не нужно таскать свою раскладку на флешке, а можно просто иметь этот uuid, и периодически обновлять свою раскладку через gist. Главное чтобы на компе где будешь пользоваться своей раскладкой была эта программа, и всё.

Ну или эту опцию можно выключить и пользоваться только локальными файлами, всё ради вас.

Настройка раскладки через конфигурационный файл и кодогенерация

Раскладка должна задаваться не в коде, а в конфигурационном файле. Предположим наш конфигурационный файл имеет формат JSON, тогда раскладку можно задать в таком виде: 

{
  "layers": [
    [
      {
        "type": "press_with",
        "press": { "type": "basic_key", "key": "shift" },
        "key": { "type": "basic_key", "key": "a" }
      },
      {
        "type": "sequence",
        "keys": [
          {
            "type": "press_with",
            "press": { "type": "basic_key", "key": "shift" },
            "key": { "type": "basic_key", "key": "b" }
          },
          { "type": "basic_key", "key": "t" },
          { "type": "basic_key", "key": "w" }
        ]
      }
    ]
  ],
  "chords": [],
  "autoreplacements": []
}

Здесь задана клавиатура с двумя клавишами и одним слоем, без аккордов и автозамен. Первая клавиша нажмёт Shift + A, вторая клавиша напишет Btw. Главное свойство этого задания в том, что кейкод можно указывать рекурсивно, соответственно не надо писать никакой код в нестандартных ситуациях, как это принято в QMK. Тем более, если вы какой-нибудь Волька, который пилит свой Кладенец или Кошкопад, для которых надо обязательно писать свою прошивку ввиду их сложности, то вы можете не писать свою прошивку, а написать программу, которая по вашему конфигу и вашему представлению генерирует такой JSON-файл. Можно сделать макросы на Lisp/Scheme по генерации такого файла. А можно и сделать визуальный конфигуратор, который будет выплёвывать такой JSON. Или, благодаря магии Serde, такой код можно писать вручную не в виде JSON, а в любом удобном для вас формате: YAML, Ron, S-expressions итд.

Для софта этот файлик будет интерпретироваться, а для прошивки он будет производить кодогенерацию. Для кодогенерации каждому кейкоду здесь будет представлен собственный номер: 

0: { "type": "basic_key", "key": "shift" },
1: { "type": "basic_key", "key": "a" },
2: { "type": "press_with", "press": 0, "key": 1 },
3: { "type": "basic_key", "key": "b" },
4: { "type": "press_with", "press": 0, "key": 3 },
5: { "type": "basic_key", "key": "t" },
6: { "type": "basic_key", "key": "w" },
7: { "type": "sequence", "keys": [4, 5, 6] },

Далее для всех этих клавиш в прошивку будет просто поставлен большой switch, в котором вызываются соответствующие функции обработки. При этом можно посмотреть на используемые кейкоды и тупо выкинуть всю ненужную информацию из прошивки, как например код для обработки аккордов итд. Они могут просто отсеяться на этапе линковки, потому что ничто их не вызывает.

Ещё можно сделать так, чтобы в этом конфигурационном файле сразу задавались цвета и подписи на клавишах, чтобы потом из этого конфига генерировать картинку в формате PNG/SVG/PDF. Опять же, благодаря тому что этот json-файл можно генерировать самому, можно написать собственную программу, которая будет рисовать цвета раскладки по вашим зонам, или будет задавать цвет определённому типу клавиш автоматически (слоефикаторы — зелёный, макросы — синий, базовые кейкоды — красный итд).

Благодаря тому что раскладка задаётся через конфиг, этому может научиться любой не-программист, и можно сделать адекватные сообщения об ошибках, в отличие от QMK, где сообщения об ошибках в препроцессорных макросах поймёт только бывалый Си-программист.

Так же без всяких костылей можно будет легко сделать визуальный конфигуратор, который не настолько слаб, как Oryx, а способен поддерживать фичи любой сложности. В крайнем случае можно использовать комбинацию визуального конфигуратора и ручного редактирования конфига.

Визуальный конфигуратор

Раз для задания раскладки надо всего-лишь сгенерировать конфиг в формате JSON, то для этого можно сделать визуальный конфигуратор, который будет выплёвывать эту джейсонину.

Каждый пользователь просидит в программе-конфигураторе дай бог хотя бы несколько часов за всю свою жизнь, а значит можно будет пойти на много компромиссов в плане производительности и так далее.

А значит можно написать интерфейс на ImGui, в котором я очень сильно прокачался в последнее время, и про который написал статью. Интерфейс будет не идеальный, но кого это волнует? Когда на QMK раскладку надо задавать через код и страдать с компиляцией, всем будет пофигу что у меня интерфейс будет выглядеть не идеально.

Вообще я считаю визуальный редактор самой главной фичей которую надо сделать для nomk, тогда количество пользователей может скакнуть на порядки относительно QMK.

Абстрактные нажатия и разделение ответственности

Код для обработки нажатий, для обработки аккордов и превращения их в нажатия клавиш, и всё то же самое для mod-tap, автозамен и слоёв, должен быть абстрактным и независимым ни от ОС, ни от ораски/фираски, ни от фреймворка (!). Данный код можно полностью отделить от кода работы со всем остальным. Благодаря чему данный код, например, можно будет тестировать локально на компе, писать юнит-тесты, а затем использовать этот код внутри прошивки и знать что твоя прошивка работает идеально, и что она будет работать точно так же в виде ораски.

Либо должна быть возможность этот модуль заменять/улучшать, чтобы вместо него вы могли вставить свои скрипты на Python, например, или вообще написать отдельный проект, который специализируется исключительно на обработке нажатий.

Таким образом мы отделяем бэкенд от фронтэнда. И бэкенд может заниматься всеми сложными вещами в виде: нажатия юникодных символов для любой системы, перехода в окно по его названию/классу для любой системы итд, работы с usb, работы с беспроводной частью, работы с низкоуровневыми железными вещами итд.

Слой кастомизации

Должна существовать возможность расширять возможности данного фреймворка без добавления к нему кода, и без перекомпиляции всего проекта. Такая возможность должна существовать через какой-то протокол, который можно реализовать на любом языке.

Например, вы хотите чтобы у вас была особая клавиша, при нажатии которой данный фреймворк в этом протоколе посылает некоторое событие, а далее через свой скрипт на Python вы считываете это событие и делаете какие-то действия.

Фокусировка на максимально сложных и нестандартных раскладках

Модуль для абстрактной обработки нажатий должен поддерживать самые сложные виды аккордов, должен поддерживать возможность любой кастомизации автозамен, mod-tap и прочего. Он должен быть сфокусирован на том, чтобы давать пользователю не виданный прежде контроль над раскладкой.

Для достижения этого я лично буду общаться с потребителями самых сложных раскладок: Волькой, Kanazei, Антик, Pupos, и буду создавать модуль для абстрактных нажатий таким, чтобы сделать все фичи, которые необходимы им.

Так же я лично буду пытаться закодить Кладенец, Стено и Frogpad исключительно через конфигурационный файл.

Иными словами, конфигурационный файл/абстрактные нажатия должны быть максимально сильны. Настолько сильны, чтобы писать новый код приходилось примерно никогда.

Ошибки существуют

Одной из фичей, которая планируется в задании раскладки — это автозамены. Автозамена — это когда после нажатия определённого набора клавиш, нажимаются не сами эти клавиши, а что-то вместо них. Простейший пример автозамены — это если вы пишете «btw», то оно автоматически преобразуется в «by the way».

В Linux есть свои системные автозамены, которые задаются через файл .XCompose. Но одна из главных проблем этого файла в том, что он предполагает что пользователь всегда прав, и ошибок быть не может. Соответственно у него нет никакой системы индикации пользователю когда он не прав, или когда он может сделать что-то лучше. Например, если у вас задано что <Compose> <3> <4> набирает дробь ¾, а другая автоматически генерируемая автозамена из <Compose> <3> <4> <5> набирает китайский символ, то вы никогда не сможете набрать этот китайский символ, и у вас всегда будет набираться эта дровь и 5. Либо же у вас просто будет конская задержка между появлением символа автозамены после набора текста (чтобы дождаться вдруг будет 5, чтобы набрать другой символ без backspace'а). Софт XCompose в таком случае ни слова вам не скажет, и вам определять такие явно ошибочные ситуации придётся на практике.

Я же хочу, чтобы такие ошибки определялись заранее, ещё на этапе считывания раскладки. Если раскладка содержит ошибки, то программа с ней не должна запускаться, либо к ней не должен генерироваться код фираски.

Ещё во всех возможных случаях должен быть способ сообщить пользователю что что-то не так, логированием Warning'ов в особое место.

Рекурсивное нажатие клавиш

Если одна фича нажимает Shift, а затем другая фича снова нажимает Shift, то при отпускании Shift'а второй фичей, он не должен отпуститься, а у него просто всё это время должно делаться ±±1, и отпускаться он должен только при достижении значения 0. И вообще в таких случаях должно посылаться предупреждение куда-то о том, что это потенциальный баг.

Абстрактные действия

Помимо кода для обработки абстрактных нажатий, должны поддерживаться «абстрактные действия».

Самые простые абстрактные действия, которые поддерживаются в QMK:

  • Нажатие любой клавиши на клавиатуре

  • Отправка любого события мыши

Новые абстрактные действия, которые хочется поддерживать:

  • Отправка любого юникодного символа

  • Включение окна по его названию/классу итд

  • Возможность смотреть на имя/класс текущего окна, и в соответствии с этим производить различные действия

  • Последовательность чего угодно из этого списка

Благодаря этому можно будет сделать ОС-независимые символьные раскладки; ОС-независимые возможности включения окна; кнопки Copy/Paste, которые способны смотреть на то, если сейчас окно терминала и соответственно использовать разные хоткеи: Ctrl/Shift+Insert или Ctrl+C/V.

Абстрактные действия возможно поддерживать только на стороне ОС/драйвера. На стороне фираски они могут эмулироваться/костылиться через простые абстрактные действия.

Скачивание раскладки из интернета

Если прошивать в клавиатуру свою раскладку, то можно просто внутри клавиатуры написать uuid, чтобы клавиатура его посылала, а программа на компе будет обращаться к gist.github.com, и скачивать json раскладки. Таким образом даже свою раскладку на флешке таскать не надо, надо только иметь эту прогу, скачанную у другого человека.

Либо чтобы посылалась ссылка на раскладку на любом другом сайте.

Это лишь дополнительная опция, и должна сохраняться возможность запускать раскладку через локальный файл.

Конкуренты

KMonad.

Интересные фичи:

  • Запуск произвольной консольной команды по нажатию кнопки cmb-button.

Такого быть не должно.

Объясняю что происходит в этой строчке. Там написано что клавиша md4 нажимает %, и при зажатом проценте нажимает маленькую латинскую букву b. И в коммментах написано что в результате будет не %b, а %B, потому что чтобы нажать процент и удерживать его нажатым требуется зажимать шифт. А это значит что мы (пользователи) должны знать строение раскладки qwerty чтобы знать что при определённых ситуациях у нас будет лишний шифт. Этой строкой я хотел показать что nomk обязан сам отслеживать нажатие шифта для набора больших букв или символов, чтобы даже если мы написали что маленькая буква b нажимается при зажатом проценте, чтобы она оставалась маленькой автоматически.

Идеи

Эти идеи не гарантируются к исполнению, а просто в идеале хотелось бы иметь и их.

Одновременно прошивка для мыши

Хотелось бы засунуть эту прошивку внутрь мыши, чтобы она могла не только передавать движения, но ещё и иметь слои на клавишах (а то клавиш то очень мало, а всякие «Страница назад» и «Страница вперёд» это такая бесполезная чушь, что просто жалко что эти клавиши простаивают), и вообще иметь возможность при нажатии клавиши на мыши, переключать слой на клавиатуре.

Клавиатура как флешка

u/SteveKey говорит:

Мне кажется, что будет удобным прошивать в клавиатуру некую «базовую» программу, которая будет видна через USB как флешка, куда можно будет закидывать свои раскладки. А в компьютере должен быть просто «свой» драйвер USB, который будет корректно обрабатывать запросы клавиатуры, но не будет содержать никаких раскладок, никаких словарей и прочего.

Идеальный протокол

Экранная клавиатура

Озвучил подруге-дизайнерше свою идею nomk, и она сказала что конкретно это ей не интересно, а интересно было бы иметь просто окошко с всякими символами, которые она настроит, чтобы она могла мышкой нажимать и получать их в поле ввода. Пример символов: кавычки-ёлочки, всякой длины тирэшки, итд.

А учитывая что я могу переиспользовать код, можно будет сделать вообще чтобы в этом окошке можно было нажимать слои итд.

Очень напоминает идею u/Steve_Key об экранной клавиатуре osk, но не такую радикальную как полный отказ от физической клавиатуры в угоду виртуальной, а что-то среднее.

Должен быть хороший юзкейс для обычных людей.

Ещё можно сделать чтобы это окошко показывало в принципе текущую раскладку, а если нажал кнопку слоя, то показывало что есть на этом слое.

Запись мыши

Помимо записи действий на клавиатуре для их дальнейшего анализа, можно сделать запись нажатий и положения мыши, чтобы потом: строить хитмап кликов и положения; измерять пройденное расстояние; графики распределения скорости итд. Не знаю зачем это нужно, но звучит прикольно. Так же наверное можно сделать чтобы и клики мыши и действия на клавиатуре замерялись одновременно чтобы можно было анализировать с какими клавишами чаще всего происходит клик мыши, или какие комбинации клавиш нажимаются в момент когда двигается мышь (например, Ctrl+W). Благодаря такому можно будет анализировать какиех хоткеи нужны при активном использовании мыши и что их надо вынести на левую руку.

Ориентация на простых людей

Простые люди не будут знать что такое слой, как сделать аккорды итд. Они наверняка придут с одним вопросом: «Как мне сделать чтобы на комбинацию Ctrl+Alt+2 писалась кавычка-ёлочка?!». Поэтому для них надо спроектировать фичи так, чтобы такие вещи делались очень просто.

Либо сделать отдельный визуальный конфигуратор специально для таких простых юзкейсов.

Включение превью клавиатуры

Вот сделал я сложную раскладку, сделал ещё слой с юникодными символами. А как мне во время печати вспоминать что где лежит? Печатать листочек и клеить рядом с монитором хоть и выход, но не очень удобный. Особенно в моём случае с 11 слоями. И перепечатывать при каждом мелком изменении ещё хуже.

Я думаю можно ввести клавишу, которая при нажатии просто берёт и показывает текущий слой по центру экрана. Скажем захочу я написать символ на юникодном слое, а у меня там дофига редких символов, которых много и положение которых я выучу ещё очень нескоро. В таком случае такое превью просто идеально. Ещё в нём можно показывать текущие нажатые клавиши. Можно сделать чтобы были ещё клавиши, которые просто включают превью раскладки как окно, чтобы оно висело и его можно было ресайзить.

Особенно учитывая что визуальный редактор изначально будет делаться как форк kle, должно получиться отлично. Эта идея должна быть максимальным бустом для новичков.

Почему у меня получится?

Я сделал такие вещи как:

  • lang_shift — задание русской и английской раскладок в QMK без вмешательства на стороне ОС.

  • combo — очень продвинутое расширение для QMK, позволяющее сделать аккорды, которые способны нажимать что угодно, а не как в QMK, только стандартные кейкоды. Внизу даже есть конечный автомат обработки аккордов. То есть сложные фичи мне поддаются.

  • Одна из самых сложных, продуманных и замороченных раскладок во всём рунете, про которую написал статью: «Раскладка Ильи Шепрута».

  • Очень продвинутые интерфейсы на ImGui. Про ImGui и примеры того что я делал, написал статью. Так что визуальный конфигуратор тоже смогу сделать.

Учитывая такие достижения мне хочется верить что такой проект смогу потянуть.

Ну и ещё у меня есть огромная мотивация по созданию такого проекта, потому что постоянно пользуюсь раскладкой и постоянно вижу как простые люди страдают от компиляции QMK.