Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Renew Ecosystem #34

Open
Diwamoto opened this issue Feb 25, 2024 · 3 comments
Open

Renew Ecosystem #34

Diwamoto opened this issue Feb 25, 2024 · 3 comments

Comments

@Diwamoto
Copy link

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.

  • Too many keyboards growing in targets.

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を使ったキーボードファームウェアとしてこのリポジトリは相当の価値があり、今後も発展を祈る所存ですが、ファームウェア戦略に一部意見を述べたいです。

  • targets内キーボードが増えすぎる。

QMKの例のように、今のディレクトリの形式だと今後もtargetsフォルダにキーボードが増え、それらのメンテナンスのために多大な労力を使うことになると考えます。
ZMK等で使用されている通り、このリポジトリはあくまでフレームワークとして機能し、ユーザが使うキーボードプロジェクトには"参考"として存在するべきです。

→ よって、ユーザは一つもしくは複数のキーボード用リポジトリを持ち、それらがビルドされる際にgoのmoduleを介してダウンロードされるべきです。

これらの問題を意見として述べるため、fork 先にfeat/renew_ecosystemブランチを作成し、ビッグバンPRを作る予定です。

@sago35
Copy link
Owner

sago35 commented Feb 26, 2024

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
Copy link
Author

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
Copy link
Author

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants