azooKey
azooKey copied to clipboard
ensan-hcl
azooKey: A Japanese Keyboard iOS Application Fully Developed in Swift
**Is your feature request related to a problem? Please describe. (提案は利用上の問題に関連していますか？記述してください。)** 着せ替え機能において、キーボードの文字の色は通常キーでも特殊キーでも同じになっているが、これを別々に設定したい。 **Describe the solution you'd like (あなたの考える解決策を記述してください)** 別々に設定できるようにする --- 所感 * 主な難しさはUI側。キーの色を一括で変更できたほうが楽だと思うので、「高度なオプション」としてこの機能を入れる必要がある * その問題さえ解決できれば追加すること自体は可能だと思う
再現手順は不明だが、稀にキー音が爆音で鳴る問題がある。おそらくConcurrency周りと推測しているので、可能な範囲で修正したい。
azooKey Version 2.4で取り組む機能・改善の案出し・議論 ## 変換 品質・パフォーマンスの向上に注力する。特に誤り訂正を改善したい。 ### Async API * https://github.com/ensan-hcl/AzooKeyKanaKanjiConverter/issues/26 非同期APIを実現する。これにより、次のような効能を期待する。 * 再変換がキャンセル可能になる * 一部のデバイスでより安定して変換できるようになる ### 変換精度 * #170 の最終的な解決を実現する。 ### 誤り訂正 誤り訂正を既存の高負荷・低精度のものから、確率モデルベースの低負荷・高精度のものに切り替える ## バー系UIの改善 タブバーはVersion 1.6で導入して以来全然アップデートしていない。 * #346...
Version 2.3以降ではiOS 15のサポートを終了するため、iOS 16以降のAPIを利用できる。 * SwiftUIのiOS 16以降のAPI - [x] `Grid `と`Layout`周りをまずは積極的に調査・採用したい - [x] `requestReview`を使いたい (https://zenn.dev/littleossa/articles/8abbf621963922) - [ ] `ShareLink`を使いたい - [x] `PhotosPicker`を使いたい - [ ] 複数行のテキストフィールドを検討 (https://developer.apple.com/documentation/swiftui/textfield/init(_:text:prompt:axis:)-9r5m8) - [ ]...
現在MainAppで管理されている`Localizable.xcstrings`をAzooKeyCoreの側に移行する
Version 2.3でタブバーの改善に取り組みたい。 ## 常時表示 タブバーを常時表示したいという要望がある。予測変換が表示されていない場面にタブバーの常時表示を行うのは可能である。 ## 固定幅 現在のタブバーはスクロール可能だが、これを固定幅にするオプションが考えられる。表示領域が限られる代わりに、タブバー上にカーソル移動UIを設置したりできるようになる。 ## アイテム種類の追加 現在は単なるボタンしか置けないが、ここに次のようなアイテムを置けるようにすることができる。 * カーソル移動のUI * ポップアップメニュー (Picker) * 長押し可能なアイテム
現在のazooKeyでは半角の?と全角の？を単に並べているため、ぱっと見ではどちらがどちらなのかわかりにくいことがある。これを例えば?半角と？全角のように表示し分けることで、選ぶ記号を区別しやすくしたい。 この付加的な説明は「`description`」として一般化したい。以下のような`enum`を用いて表示側で調整を行うイメージである。 ``` enum CandidateDescription { case halfWidth case fullWidth // ... } ``` 以下のような実装が必要になる。 - [ ] 候補のdescriptionを表示するUIを作成する - [ ] 半角・全角の表示が必要な候補であるかどうかを判定するモジュールを用意する
#142 や #160 でGoogle Formをアプリに埋め込む形の実装をした。これまで「機能の要望」「不具合の報告」はGoogle Form経由で募集していたが、これもアプリに組み込むことで使いやすくなると思う。 利点としては * ブラウザを開く必要がない * バージョン情報をユーザに入力させずに済む * ネイティブUIに寄せられる 欠点としては、何を送信しているのかユーザに自明ではないことが挙げられる。 とはいえ、おそらく正しい方向だと思うので、このようにしたい。
入力管理（カーソル移動判定、ペースト判定など）は現在UserActionManagerの機能となっているが、これを`UIInputViewController`のサブクラスにおいて提供することができる。 こうすることで、次のメリットがある。 1. 単体テストができる 2. 入力管理が単体で切り出せてメンテナンスが楽になる さらに、将来的には単体で独立のパッケージとして公開することもできる。
プライベートなAPIであること、特に現状必要がないことから使うことはなさそう。 ```swift // このcomputed propertyをKeyboardViewControllerに追加 @objc var markedText: NSString { fatalError("Do not directly call this getter") } ``` ```swift // trueになる debug("markedText", self.textDocumentProxy.responds(to: #selector(getter: markedText))) let result = self.textDocumentProxy.perform(#selector(getter: markedText))...