[FEATURE] 3段フリック周りのリファクタリング
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- kotlin
- Domain
- mobile-dev
Research direction
Review KeyboardDefaultLayouts and TfbiFlickNode.StatefulKey, then trace the controller’s angle handling and existing three-stage flick definitions. For the first small PR, define the neutral schema and mapper for existing three-stage flick data; filters, boundary metadata, and UI editing are later follow-ups.
Written by the indexing model from the issue text.
Description
この機能リクエストは、何か問題に関連していますか？説明してください。
3段フリック周りを今後拡張しやすくするため、段階的にリファクタしたいです。
現状の KeyboardDefaultLayouts では、3段フリックの候補ツリーが TfbiFlickNode の runtime 構造として直接手書きされています。
そのため、候補の出し分け、角度判定の拡張、将来的なカスタムキーボード対応を入れるたびに、巨大なデフォルト定義へ条件分岐を足す形になるので保守性が下がるのではと懸念しています
望む解決策を説明してください
まずは runtime 用の TfbiFlickNode とは別に、保存・編集・生成に使える中立の flick definition schema を追加したいです。
最初の対象は3段フリックですが、設計としては「キーに対して、方向ごとの候補ツリーを持つ」汎用的な schema に寄せる予定です。
これにより、将来的には通常フリックや二段フリックも同じ定義モデルから runtime map へ変換できたらよいと考えています
schema から TfbiFlickNode.StatefulKey へ変換する mapper によって既存の3段フリックを移行できたら，以下を進めたいです
- デフォルト3段フリック定義をgenerator経由に
- きゃ/きゅ/きょ や きゅう/きょう のような候補を各行で重複して手書きする必要をなくします
- あ行二段目候補を無効化する機能を追加
- schema の feature filter として実装
- 「ぁ」や「ゔ」など使用頻度が低い割に誤判定されがちな候補を無効にできるようにしたいです
- 判定角度調整を一般化
- #851 にてイ段の濁音/拗音境界向けに入っている角度調整を、方向ペアまたは候補境界単位で扱えるように一般化
- schema 側に boundary metadata を持たせ、controller 側は metadata に従って判定する形へ寄せる想定です
- カスタムキーボードで3段フリックを選択可能に
- schemaをUI上で保存・編集できるようにします
各PRは可能な限り小さくするように努めます
全体の方向性など、ご意見いただけますと幸いです
追加のコンテキスト
- https://github.com/KazumaProject/JapaneseKeyboard/issues/535
- https://github.com/KazumaProject/JapaneseKeyboard/issues/702
- 将来的にバッティングする可能性もあるのでこのあたりは協力して進めたいです
- Dominant language
- Kotlin
- Stars
- 345
- Forks
- 36
- Avg merge
- 10h 10m
- Merged PRs (30d)
- 99
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from KazumaProject/JapaneseKeyboard
-
ユーザー辞書や定型文で単語の末尾スペースが削除される（登録経路による挙動差）Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
KazumaProject/JapaneseKeyboard#1125 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
KazumaProject/JapaneseKeyboard#1089 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
KazumaProject/JapaneseKeyboard#1102 · 3 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
KazumaProject/JapaneseKeyboard#1100 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
KazumaProject/JapaneseKeyboard#1096 · 1 reaction ·
Maintainers usually reply within 1 day
All issues in KazumaProject/JapaneseKeyboard
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
rustyrazorblade/easy-db-lab#1003 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
droidconKE/droidconKeKotlin#426 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
MuwMx/YumaPlayer#101 · 1 reaction ·
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
IBRAHIMDANS/i18nSupportPlus#370 · 1 comment ·
Maintainers usually reply within 1 day