Open Diwamoto opened 9 months ago
sago35
commented
9 months ago Thank you for sharing your thoughts. Indeed, I agree that having an increasing number of targets can become an issue. Additionally, KiCad data might not be essential. I believe there is a need to split the repository in some way. Personally, I think it would be beneficial to reduce it to only a few representative keyboard implementations, also for the sake of testing.
Diwamoto
commented
9 months ago KiCad data might not be essential
Yeah, I agree. We believe that this repository belongs to you and that you should be the final arbiter of where this repository goes.
We are still working on the architecture of the PR I mentioned the other day, but when the PR is ready, we can discuss whether it should be merged into this repository, or whether it should be a separate repository with a new commit log stacked on top of it.
Diwamoto
commented
9 months ago I would like to decide on some kind of project name. tinygo covers the parent and namespace, and keyboard covers machine/usb/hid/keyboard. How about TGK(TinyGo Keyboard)_firmware for example, like other firmware projects for keyboards such as qmk and zmk. It would be interesting to give it a more unique name. (I can't think of one, lol)
The Japanese version is at the bottom.
What is this Issue?
[IMO] I want to change the way it is as a framework. As a keyboard firmware using tinygo, this repository has considerable value and I wish it continued growth, but I would like to offer some input on the firmware strategy.
As in the QMK example, the current directory format will continue to increase the number of keyboards in the targets folder, and a great deal of effort will be expended to maintain them. As used in ZMK and others, this repository should only serve as a framework, and should exist as a "reference" for user keyboard projects. → Therefore, users should have one or more keyboard repositories that are downloaded via go's modules when they are built.
I will create a feat/renew_ecosystem branch at the fork and a big bang PR to voice my opinion on these issues.
Japanese
[個人的な意見です] フレームワークとしてのあり方を変えたいです。 tinygoを使ったキーボードファームウェアとしてこのリポジトリは相当の価値があり、今後も発展を祈る所存ですが、ファームウェア戦略に一部意見を述べたいです。
QMKの例のように、今のディレクトリの形式だと今後もtargetsフォルダにキーボードが増え、それらのメンテナンスのために多大な労力を使うことになると考えます。 ZMK等で使用されている通り、このリポジトリはあくまでフレームワークとして機能し、ユーザが使うキーボードプロジェクトには"参考"として存在するべきです。
→ よって、ユーザは一つもしくは複数のキーボード用リポジトリを持ち、それらがビルドされる際にgoのmoduleを介してダウンロードされるべきです。
これらの問題を意見として述べるため、fork 先にfeat/renew_ecosystemブランチを作成し、ビッグバンPRを作る予定です。