1文字目の入力がもたつく現象について調査する。

Environment (環境を詳しく教えてください):

• App Version: develop:3fcfaa9537445ad53a138943588a0915d731cae8

おそらくフォントの変更が原因

前提
craft.doというアプリケーションでazooKeyがうまく動作しないとの報告をいただきました。
以前ScrapBoxでも類似の内容が報告されています。

エディタ系アプリケーションとの相性の問題はあるのですが、craft.doについては「入力中のテキストを保護」で解決しました。

対応
全てのケースに対応できるとは限らないのですが、「入力中のテキストを保護」をオンにするよう促すドキュメントを追加しても良さそうです。

Xcode 14.3でSwift5.8が来る予定で、そのタイミングでおそらくコンパイルフラッグが使えるようになる。これを利用してbare P -> any Pの移行を進める。

Version: 2.1

Describe the bug (不具合を説明してください)
フローティングキーボードが縦長に表示され、下に変な空白が生じることがある。

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)
わからない。生じることも生じないこともある。

Expected behavior (どういう動作になるのが正しいと思いますか？)
正しいサイズで表示される。

Screenshots (スクリーンショットがあれば添付してください)
ない

Environment (環境を詳しく教えてください):

• Device: iPad pro 11 inch
• iOS / iPadOS and its version: iPadOS 13.3
• App Running Keyboard: Any
• App Version: 2.0.1

現在、本体アプリ側でneedsInputModeSwitchkeyを取得するためにデバイスの判定を行っているが、どうやらUIInputViewControllerのインスタンスを作ることで簡単に取得できる。こちらに移行することでコード量を減らすことができる。

Describe the bug (不具合を説明してください)
「つかった」などで「塚った」が一番になる。

Environment (環境を詳しく教えてください):

• App Version: 2.0.1

現在、FlickキーボードのデータとCustardのフリックタブはそれぞれ独立に扱われているが、そろそろ統一して問題ない。

数字タブの記号の表現のみ難しいため、要検討となる。

Swift6に向け、azooKeyでも--enable-upcoming-feature StrictConcurrencyを導入する必要がある。 #147 ではクラッシュに対応するため一部の宣言で@MainActorを導入した。
--enable-upcoming-feature StrictConcurrencyには何度か挑戦していて、その度に「これは相当厄介である」と思って先送りしてきている。Version 2.2でこの問題に最終的に取り組む予定である。

#106 の作業中に、フリックのカスタムタブ編集中、プレビューが更新されない問題を発見したので、修正する。

ユーザが積極的に変更したい設定ほど上位にあるべきである。

• キーボードの種類を設定する
  （妥当）
• 言語を設定する
  （通常、ユーザは日本語と英語があれば十分なので、この設定は上位すぎる）
• フリックの感度
  （これもどちらかというと高度な設定なので、上位すぎる）
• カスタムキー
  （azooKeyのメイン機能の1つなので、ここにあるのは良い）
• ペーストボタン
• タブバー
• カーソルバー
• サウンドと振動
  （これはもう少し上位でも良い）
• 表示
• ライブ変換
• 変換
• ユーザ辞書
• テンプレート
• 学習機能
• カスタムタブ
  （重要だが、専用でタブを立てているのでこの位置で十分）
• このアプリについて

Google Formからの機能追加の要望で、片手モードが有効化されている場合、空いたスペースに3つのボタン(リサイズ、解除、リセット)を表示しているが、これを誤ってタップしてしまうため、非表示にしたいとのこと。

• positive
  • 普段から片手モードで使う人には鬱陶しい可能性がある
  • タブバーに「片手」があるので、解除に困る心配はない
• negative
  • 特になさそう。実装としてもフラグ1つで済む

実装する予定。

Google Formからの機能追加の要望で、カスタムタブを誤って消去してしまったが、復旧できないため、復旧可能にしてほしいとのこと。
現在の仕様では、カスタムタブや着せ替えの「削除」を実行した際、物理削除が行われるため、復旧は不可能になる。

復旧機能は必要だと思うが、どのように実装すべきかという点で検討の余地がある。

• options
  • 削除のタイミングで「本当に削除しますか？」を入れる
    • positive
      • 最も軽量で妥当
    • negative
      • 実装上少しだけ複雑になる可能性がある？
  • 削除後にn日間保存する(写真App方式)
    • positive
      • 機能としては必要十分だと思う
    • negative
      • 'n日後に実行する'というような実装は難しそう
  • アーカイブにする（完全削除はアーカイブからもう一度削除する）
    • positive
      • 実装は簡単になりそう
    • negative
      • azooKey内のUIとして前例がない

あまりにあちこちで使っているため消せなくなっているVariableStatesだが、シングルトンを多用するのはよくないし、Viewの更新がどこで走るか予測がつかない。更新の流れを整理し、VariableStatesを無くしたい。

Is your feature request related to a problem? Please describe. (提案は利用上の問題に関連していますか？記述してください。)
「かっこ」の変換で()のみが表示されるのが不便だという指摘をいただきました。

Describe the solution you'd like (あなたの考える解決策を記述してください)
かっこの変換で、「」の変換と同一のバリエーションを表示するのが良さそうです。

Describe the bug (不具合を説明してください)
「明後日」が「あさって」で変換できない。

Environment (環境を詳しく教えてください):

• App Version: 2.0.2

DicdataStore内の辞書検索で、learningManager由来の候補を作ったあとにペナルティが適用されなくなっている。
大きな不具合にはつながらないが、直すべき。

Version 2.2のPlanningに匿名でコメントしたい方はこちらのGoogle Formをご利用ください。

https://forms.gle/jtNJHN33EhBjfK1H6

Version 2.2ではUI側よりも変換側にフォーカスする。具体的には以下をターゲットにする。

• 処理速度の向上 (#4 など)
• 辞書フォーマットの再検討 (#135 など)
• テストケースの追加

また、リファクタリングを積極的に進め、よりメンテナンスしやすいソースコードを目指す。具体的には、以下を検討していく。

• 並行性への対応 (#148 )
• @KeyboardSettingの見直し
• ディレクトリ構造の改善
  • 特に、変換モジュールの独立化

iOS 17は2023年6月のWWDCで発表され、ベータリリースが公開されると見られる。Version 2.2ではiOS 17対応もスコープに入る。iOS 17の正式リリースは9月中旬と期待されるため、目標としては9月上旬までにVersion 2.2をリリースできれば問題ない。

このように、Version 2.2ではある程度時間をかけて開発に取り組むことができると考えられる。アプリ全体をブラッシュアップする方向で開発を進める。

おそらく #73 と同じ問題

以下強調したい。

• 基本的には不要であること
• フルアクセスがないと実現できない機能のためにしか使っていないこと
• OSSであり、実装を確認できること

Describe the bug (不具合を説明してください)
iPadのフローティングキーボードでazooKeyを利用すると、キーボード全体が縦に潰れてしまい、とても使いづらい

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)
Steps to reproduce the behavior:

1. 一度標準キーボードを開く
2. キーボード上でピンチ操作を実行し、フローティングキーボードを有効化する
3. この状態で地球儀キーからazooKeyを選択する
4. azooKeyが潰れて表示される

Expected behavior (どういう動作になるのが正しいと思いますか？)
iOS版で表示されるようなキーボードが表示される

Screenshots (スクリーンショットがあれば添付してください)

Environment (環境を詳しく教えてください):

• Device: iPad Pro
• iOS / iPadOS and its version: iPadOS 16.3
• App Running Keyboard: Any
• App Version 2.0

Additional context (その他共有したい事項があれば記述してください)
この問題は既知で、今まで報告があまりなかったので後回しにしていた。
キーボードのサイズ決定周りは挙動が難しいので、難航しそう。

前提
不具合として、特定のアプリでazooKeyが表示されないとの報告をいただきました。

ほとんどの場合これはazooKeyの問題ではなく、以下のどちらかの場合です。

• azooKeyを入れてすぐの場合、OS側の不具合で特定の環境でキーボードが表示されないことがある→この場合、再起動が必要
• アプリ側でKeyboard Extensionの利用を禁止することができるため、そちらの可能性がある→この場合、どうしようもない
  ただし後者のケースはメジャーなアプリではまだ見たことがありません。

対応
「困ったときは」に、以上をわかりやすく説明して書けると良さそうです。

いくつかのアプリケーションは「連絡先」の名前を読み込む機能を持っているので、これを実現する方法を検討する。

学習機能について以下を検討する予定。

編集

現在、一度学習した候補を削除する方法がない。しかし、誤変換を学習してしまう場合には学習を削除できた方が良い。

アイデア1. 長押しして削除

Android版のGboardは候補を長押しすることで削除できる仕様となっている（先頭の候補に限る）。このUIは「大きく表示」が可能なazooKeyでも実現しやすい。

課題

Candidateが学習済みのデータに由来するものであるかを判断する方法が、現状ない。このため、「長押しして削除」の実現には、

• Candidateにそのような属性を付与する
• 「削除」を要求された時点で再検索を実施する
• より一般的なメカニズムとして「抑制」を加える

などの方法が考えられる。1つ目の方法はかなり難しい。2つ目の方法はパフォーマンス上問題があるため、全てのCandidateで「削除」と出しておいて学習による候補でなければ「失敗しました」とする羽目になる。3つ目の方法は理想的だが、「抑制」ではフィルタが無制限に肥大するため、慎重な実装が必要となる。

現実的なのは2つ目の方法で、「この候補の学習をリセット」といった表示を行うと、「学習による候補ではない場合」に「失敗」させる必要がないかも知れない。

アイデア2. エディタの実装

上記の問題を短期的に解決する方法として、簡単な学習のエディタを作成する方法がある。このUIは前例がなく、やや煩雑となる一方で、明示的にロード処理を挟むことができるため、「『削除』を要求された時点で再検索を実施する」にあるパフォーマンスの問題がない。

プライバシー

キーボード上から「新たな学習を停止（プライベートモード）」「これまでの学習を利用しない（ゲストモード）」を有効化できることにより、ユーザがプライバシーを守りやすくなる可能性がある。

この機能の技術的な課題はキーボードからの設定の上書きである。上書きそのものは、設定の構造を次のようにすることで対応できる。

• アプリ側：App Groupの共有領域に「(設定内容, 更新日時)」のデータを保存
• キーボード側：Private領域に「(設定内容, 更新日時)」のデータを保存
• 読み出し：更新日時の新しい方を利用

しかし、キーボード側から上書きした場合にアプリ側の設定の表示を更新する方法が存在しない（フルアクセスがある場合は表示を更新できる）。これが実際の使用感にどれほど悪影響を与えるかは不明であり、おそらくあまり気にしなくて良いと思う。

また「ゲストモードの解除をキーボード上で可能にするか」という論点がある。ゲストがゲストモードを解除できたら意味がないかもしれないが、これは今後に回しても問題ないと思う。

バックアップ

学習のバックアップを定期的に取り、そこから過去の学習を復元できるようにすることが考えられる。

この機能の課題は、「復元」をどのようなUIで実現するかと、実際に「定期的に」は取れないのをどう解決するかである。

仕様の再検討

• 現在の学習は、特に長い候補において強すぎるため、弱くした方が良いかもしれない。
• 学習の上書き時の処理の安全性を確認する必要がある。loudsの書き出しにおいて一部の処理のみ失敗した場合、学習が破壊される可能性がある。

Before releasing azooKey, we have to have support for Emoji 15.0, which will be (perhaps) supported in iOS 16.4 or iOS 16.5.

Describe the bug (不具合を説明してください)
形容詞のカタカナ表記と正規形のコストが同じになっている。

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)
「面白い人」「悪い人」「嬉しい顔」などで、「オモシロイ」「ワルイ」「ウレシイ」などがトップにサジェストされることがある

Expected behavior (どういう動作になるのが正しいと思いますか？)
決して間違ったエントリーではないが、おそらくもっと評価が低い。

Environment (環境を詳しく教えてください):

• Device: iPhone 12
• iOS / iPadOS and its version: iOS 16.3
• App Running Keyboard: any
• App Version: 2.0

形態素解析向けの手法だけど、基本的にはかな漢字変換にも応用できるはず。
https://www.anlp.jp/proceedings/annual_meeting/2023/pdf_dir/C2-5.pdf

#98 で絵文字タブの実装を追加したので、実際にどのように絵文字タブを開けるようにするか考える必要がある。

1. タブバーに追加する
   デフォルトでタブバーに追加してしまう方式。これは楽で良い。

2. 既存の特定のキーに追加する
   特定のキーのバリエーションとして絵文字を割り当てる方式。TenKeyなら「あいう」キーの下フリック、Qwertyなら「123」キーの長押しなど。発見性が悪いので、1の方式との併用になりそう。TenKeyの場合、確定状態に限ってkogakiキーを絵文字タブキーに置き換えることも無しではない。

3. 分割表示の形で追加する
   TenKeyなら地球儀キーを2つに分割。
   ローマ字の場合、123 | #+= or 123 / 🌐キーの位置を3つに分割し、表示する。
   どちらも設定で拒否可能にできる必要がある。

4. タブバーボタンの右側や左側に追加する
   無しではないが、主張しすぎるのでなるべくやりたくない。

Describe the bug (不具合を説明してください)
「入力中のテキストを保護」で確定していない入力がある状態で、「close_keyboard」アクションを用いてキーボードを閉じ、再度開くと、入力してあった文字列が消えてしまう。

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)
Steps to reproduce the behavior:

1. 「入力中のテキストを保護」をオンにしてキーボードを開く
2. 「あいうえお」と入力
3. タブバーの「閉じる」ボタンでキーボードを閉じる
4. 再びキーボードを開く
5. 入力済みの文字が消えてしまう

Expected behavior (どういう動作になるのが正しいと思いますか？)
キーボードを閉じた時点で「確定」扱いになるのが妥当な動作だと思う。

Environment (環境を詳しく教えてください):

• Device: iPhone 12 mini
• iOS / iPadOS and its version: iOS 16.3
• App Running Keyboard: any
• App Version: 2.0.1

iPad Proで実行時

• メモリエラー
• Variationが即座に表示されない
• 検索ボタンをタップしてもテキストフィールドにフォーカスが発生しない

iPhoneで実行時

• 片手モードを設定しようとすると表示が壊れる

Describe the bug (不具合を説明してください)
「飛ばない」「飛んでる」などで妥当な候補が表示されない不具合がある。

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)
Steps to reproduce the behavior:

1. 「とんでる」を入力する

Expected behavior (どういう動作になるのが正しいと思いますか？)
「飛んでる」「跳んでる」などが最初の候補となる。

Environment (環境を詳しく教えてください):

• Device: iPhone 12 mini
• iOS / iPadOS and its version: iOS 16.3
• App Running Keyboard: any app
• App Version 2.0

#99 で絵文字データの自動生成を達成したので、MainApp/DataSetの絵文字データも同様に自動生成できる。メンテナンスコストを下げるためにも、自動生成としたい。

#142 の方式でGoogle Formをアプリ内に仕込み、不足語彙を報告する機能を追加したい。

• アプリ内のフォーム
• ユーザ辞書に登録するタイミング

以上2点で不足語彙の報告機能を追加する。

• 1つも記録がない場合に真っ白になる不具合
• 新しい記録を取得するのに何度かかかる不具合

Describe the bug (不具合を説明してください)
テキストフィールド上の絵文字（😇）を選択すると変換候補欄に上位サロゲートが表示されてしまう。この候補は表示されるべきでない。

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)

1. テキストフィールド上に絵文字（😇）を配置する
2. テキスト選択によって絵文字を選択する
3. 変換候補欄に上位サロゲートが表示される

Expected behavior (どういう動作になるのが正しいと思いますか？)
上位サロゲートは表示されず、絵文字1文字が表示される

Screenshots (スクリーンショットがあれば添付してください)

Environment (環境を詳しく押してください):

• Device: iPhone 12 mini
• iOS / iPadOS and its version: iOS 16.3
• App Running Keyboard: メモ.app
• App Version: masterブランチ

Is it possible to keep in touch with you on an ongoing basis to fix this bug? (バグの修正のため、継続的なやり取りは可能ですか？)
Yes

Additional context (その他共有したい事項があれば記述してください)
Nothing/

Version 2.1ではフルアクセス機能が必要な機能を追加したい。

振動フィードバック

振動フィードバックは（なぜか）フルアクセスが必要な機能のため、追加する。既存の「サウンド」とは独立の設定とする。

ペーストボタン

キーボード上でのペーストが可能になるのは大きな利点であるため、実装したい。

要望の中では「改行キーの上フリック」「地球儀ボタン / カーソルバーキーのフリック」「タブバーボタンの横」など様々言われているが、デザイン上の課題として

1. iPadはデフォルトで左上にペーストボタンが表示されるため、重複して表示させない方が良い可能性がある。
2. 改行キーの上フリックは誤作動の可能性が大きく、難しい。
3. 地球儀ボタンのフリックは技術的に難しい。
4. カーソルバーキーの場合は容易であるが、地球儀ボタンを必要とする端末（現状、iPhone8系とiPhone SE系）で使えないため問題になる。iPadはデフォルトで左上にペーストボタンが表示されるため、あまり問題ではない。
5. タブバーボタンの横はデザインスペースがあるが、あまりごちゃごちゃさせたくないので要検討。
6. フルアクセスがない場合にペーストボタンを表示するかどうか。
7. CustardKitでどのようにペーストボタンを取り扱うか。
8. Qwerty配列でどこにペーストボタンを入れるか。

などがある。

現状の想定では、次のようになりそう。

• カーソルバーキーの上フリックにペーストを割り当てる
• 地球儀ボタンのフリックには対応しない
• CustardKitではpaste_actionを追加（よって、カスタムキー機能で好きな位置にペーストアクションをつけることはできる）
• フルアクセスがない場合は単に何もペーストしない（バグと見做される可能性があるため、初回のみメッセージ表示？）
• Qwerty配列では何もしない

キーボード内の設定更新

アプリ内とキーボード内の設定の動機が可能になる

• 更新サイクルなどを見直す
• 命名を見直す

Describe the bug (不具合を説明してください)
「入力中のテキストを保護」している状態でライブ変換を用いて絵文字を連続して入力すると、見かけ上のカーソルの位置がおかしくなる

To Reproduce (どのような手順で実行すると不具合が生じるのか、詳しく教えてください)
Steps to reproduce the behavior:

1. ユーザ辞書などで「はーと」に「💙」を割り当てる
2. 「はーとはーとはーとはーと」と入力すると、4つのハートが表示される
3. このとき、カーソルの位置が2文字目と3文字目の間になる

Expected behavior (どういう動作になるのが正しいと思いますか？)
4文字目の後にカーソルが表示される

Screenshots (スクリーンショットがあれば添付してください)

Environment (環境を詳しく教えてください):

• Device: iPhone 12 mini
• iOS / iPadOS and its version: iOS 16.3
• App Running Keyboard: any
• App Version: 2.0.1

Package.resolvedはあってもいいかと思っていたが、ない方が良さそうなので削除して.gitignoreに追加したい。

「文頭まで削除」の後に取り消しボタンを表示したい。 #47 の対処にもなる。

ConverterTest.testFullConversionの実行をプロファイルしたところ、律速は誤り訂正とStringをCharIDに変換する部分であることがわかった。

特に、誤り訂正のうちここが実行全体の10%を占める。この処理は誤り訂正によって算出した文字列の情報を辞書に格納しておく処理であり、予想外にコストがかかっているようである。

また、StringをCharIDに変換する操作は、StringをCharacterに分解する必要があるため低速だった。

対処方法は検討中である。

As Full Access is now officially implemented, we can remove that file.

Describe the bug (不具合を説明してください)
「フリックで全て削除」を使うと文頭までではなく変な位置まで削除される。

Environment (環境を詳しく教えてください):

• iOS / iPadOS and its version: iOS 16.3.1
• App Running Keyboard: notes
• App Version: 2.0.2

Additional context (その他共有したい事項があれば記述してください)
予想では、iOS16以降おかしくなっている。

azooKey内で絵文字タブを利用したいとの要望は以前からあり、将来的な対応を約束してきた。

#85 においてキーボード内キーボードを実装したことで、要素技術の多くが揃っており、そろそろ対応できそう。

基本的には標準キーボード志向で目指す。

表示するもの

• 絵文字キー
  • Recent Emoji (最近使った絵文字を表示する)
  • Normal Emoji (ジャンル別に絵文字を横スクロールで列挙する)
  • 特に、肌の色への対応が必要な絵文字ではVariationViewを表示できる必要がある
• 元のタブに戻るキー
• 削除キー
• ジャンルごとに遷移するキー
• 検索バーと結果の表示 (In-Keyboard Text FieldとUpsideComponentで対応する)

Data.init(contentsOf:options:)の読み込み時、オプションでmappedIfSafeを指定することでファイルを仮想メモリにマップすることができる(mmap相当)。これを使うことで、読み込んだファイルによるRAM使用量が削減され、利用可能なメモリが増えることを期待できる。

https://forums.swift.org/t/difficulties-with-efficient-large-file-parsing/23660/33