辞書画面の機能追加（ソート、検索、リスト機能強化）

[kebin628]

内容

辞書画面の機能を追加しました。

• ソート機能（読み＆優先度、昇降順切り替え）
• 単語検索機能
• 優先度リスト表示機能
• 変更伴うリストUIの調整

※ Issueにある提案機能の内、インポートエクスポート以外を実装した形になります。

関連 Issue

【提案】読み方＆アクセント辞書の機能追加 · Issue #2381 · VOICEVOX/voicevox
#2381

スクリーンショット・動画など

読み順

優先度順

サブメニュー（優先度切り替え。今後インポート・エクスポートもここに入れる）

検索機能

その他

ソートのサイズの都合、当初案のUIから多少変更になっています。

リストでの優先度表示はアプリを消しても設定が消えないようにしています。
設定画面で入れるほど大掛かりなものでないので、一時的にローカルストレージに保存できるようになっていればいいなと思って入れていますが、他に良さそうなやり方があればそちらを使います。（OnClickShowPriorityOnDictionary）

[Hiroshiba]

レビューお待たせしてしまってすみません！
型周りでエラーが出ていそうだったのでひとまずコメントまで…！
（不明な点あればなんでもお聞きください🙏）

[kebin628]

@Hiroshiba

型周りでエラーが出ていそうだったのでひとまずコメントまで…！

見方があっているか確認ではあるのですが、一緒にエラー出てる117行目と119行目の内容の話であっていますでしょうか？
ここの2行のことであればヒホさんのコードが残っている部分になるのですが、こちら側で手つけたほうが良さそうですかね？

[Hiroshiba]

@kebin628 原因の特定までできてないのですが、おそらくこのPRの変更でエラーになったんだと思います！
エラー見るに、filteredUserDictの値がなぜかnumberになるときが増えた…？

[voicevox-preview-pages]

🚀 プレビュー用ページを作成しました 🚀

• 📝 エディタ
• 📖 Storybook

更新時点でのコミットハッシュ：ce4a78f

[kebin628]

@Hiroshiba

期待する値: number | string | symbol
ビルトインの特別な属性 | Vue.js
https://ja.vuejs.org/api/built-in-special-attributes#key

すみません、該当部分でなく、エラーの本体というかきっかけとしてはv-forの返り値が原因だったようです。
今回の変更でおっしゃるとおりリストの所をfilteredUserDictという別のソートしたリストを返しているので、それの値が影響していたみたいです。
どうも、v-forで回したものがstringかnumberかになるので、使うタイミングでstringにしてやればひとまずは大丈夫そうに見えます。

それと、Mainマージしたらこっち側でエラーが出るようになってしまったため、それの対応も行っています。
発生理由としては、昨日マージした辞書画面の左右分離の影響なようです。

読み方＆アクセント辞書ダイアログの右側パネルを別コンポーネントにする by jdkfx · Pull Request #2290 · VOICEVOX/voicevox
#2290

対応内容としては、
新しく作られたDictionaryEditWordDialog.vueに半角→全角調整の変換コードが移動された影響で、メインパネルの検索欄で使用できなくなったため、他の日本語系の処理同様、当該コードを

domain/japanese
https://github.com/VOICEVOX/voicevox/pull/2411/files#diff-c6bf9942ebf63683aedebc287973adfe6b459ec6eb37118d4d6e926e13b72a95R175
に移動しています。

よろしくお願いします。

[Hiroshiba]

すみません、レビューがとても遅くなりました！！！
あれからnpmがpnpmに変わったりしました！
#2512

UIの相談をさせていただきたく･･･ 🙇

ソートUIに関して、issueの提案のようにメニューのボタンにするの良さそうな気がしてたのですがどうでしょうか 👀
別レーンにするのは･･･････横幅が足りないから的な感じですかね？だとしたらさてどう解決したものかって感じですねぇ 😇

こういうUIも良さそうな気がしました。。メニューで「並び方」と「昇順・降順」を切り替えられる感じを想像してます。

ただ今どういう並び順なのかの表示がちょっと難しい気もするのですが。。。。
良い解決策が出てない中でのコメントですみません。。。 🙇

[kebin628]

@Hiroshiba
お久しぶりです

読み順の昇順降順別表記

内部で昇順降順が分離している件については纏める事はできますが、これ今後要素増えたりしないですかね？
要素増えると並び替えパターン*昇順降順で倍々に増えていくので、現PRの「並び替えタイプ＆昇順降順切り替え分離」と「Selectに纏める」のどちらが良いのかとは。

とはいえ、今回の場合対象は現状読みと優先度くらいですし、それ以上増える要素もなさそうなので、ここは指摘の通り、対象と昇順降順をマージしてやって

• 読み順: 昇順
• 読み順: 降順
• 優先度順: 昇順
• 優先度順: 降順
  の4つにする方針も良さそうですね。

今どれにしているかの話については、SelectUIの上に現在の選択状態がそもそも出るので、「↑↓並び替える」でなく、「↑↓読み順: 昇順」で設定内容出すようにしてやれば解決するかなとは（＝「並び替える」の文字列は、設定中の値とアイコンから逆読みできるので不要なのでは）

メニュー欄の内容

ソートUIに関して、issueの提案のようにメニューのボタンにするの良さそうな気がしてたのですがどうでしょうか 👀
別レーンにするのは･･･････横幅が足りないから的な感じですかね？だとしたらさてどう解決したものかって感じですねぇ 😇

幅が割と限界ギリギリですね･･･
現状、全体に対する割合でサイドバーサイズが決められているようで、今のを踏襲すると、ウィンドウサイズによって見栄えが結構変わるのがちょっと困りものだったりしますかね。

読み順がどれに設定されているのかを表示しなくて良いのであれば、アイコンだけで完結できます。

ただ、ちょっと追加の文字が浮くので、そこが気がかりというか、気になる所ではありますかね？

解決策として、

• 上の追加の文字を他よろしくアイコンにしてしまい省スペースを図る
• 下部に追加ボタンを持ってきて上をスッキリさせる（Androidでよく見る右下＋とか）
  とかも良さそうですかね。

ひとまず、最後のやつが見栄え的には割とスッキリしてそうなので、この方向も良さそうかなと仮組みしてて感じてました。
かなり好みの違いで色々解法はありそうだなぁとやってて改めて感じてます。

余談

手元の他ソフトでどうしてるか参考資料として置きます。
ボイスピのがボイボとかなり近いですね。

VOICEPEAK

A.I.VOICE2

CeVIO AI

ひとまず詰め切るまで手は動かさないでおきます～

[Hiroshiba]

昇順降順

昇順降順に関して、それだけ独立させてメニュー内に含めてしまうのが良いのかなと思いました！
メニューとしては「読み方」「優先度」という項目と、その後にセパレーターなどを置いた後に「昇順」「降順」を置く感じとか。
ただまあこうすると普通のセレクターではなくなるので大変かもなのですが･･･。

でもデザインを変更することでもうちょっと根本的な話ができるかも！！（最後に詳細書きます）

メニュー欄の内容

追加ボタンを「＋」にする形が良さそうに思いました！
でもどういう方針にすべきかはちょっと要確認かも。

@takusea すみませんちょっと確認なのですが、プラスボタンってどこに配置する方針になってましたっけ。。
多分2択だったと思ってて、リストの一番下に「追加」ボタンを置いてもOK？あるいはメニューのとこにプラスボタン･･･？
（マルチエンジンでエンジンを追加するときは確かメニューにプラスボタンだった記憶があります。これが暫定処置だったかどうか忘れました。。）

---

既製製品の例ありがとうございます！！！！！

@kebin628 さん詳しそうなのでちょっと聞いてみたいことが！
単語辞書ってVOICEVOXやvoicepeakみたくリストと単語編集を同じ画面でできた方が嬉しいですか･･･？ 👀
それともcevioやAIVOICEみたく分けてしまって、リストの中から1つの単語を選んで単語編集モーダルが表示される方が嬉しかったりしますか･･･？ 👀

これどっちにすべきか悩んでいて、前者はいろんな単語をテキパキ編集できる一方でUIの面積が狭いからデザイン的な制約が高く、後者は一覧性が高いけど単語編集するためにやらないといけない操作が多いんですよね～～～

まあ UI を大きく変えるかどうかに関わらず、今回の実装（並び替えと検索フィルター実装）は進めても良さそうだとは思っています！！
多分デザインを変えるとなっても実装は転用できるはず。

[kebin628]

@Hiroshiba

昇順降順に関して、それだけ独立させてメニュー内に含めてしまうのが良いのかなと思いました！
メニューとしては「読み方」「優先度」という項目と、その後にセパレーターなどを置いた後に「昇順」「降順」を置く感じとか。
ただまあこうすると普通のセレクターではなくなるので大変かもなのですが･･･。

あれ、プルリクの段階のもので、それと同じ事やっていないでしょうか？
こっちは昇順降順切り替えが矢印アイコンなので、ベースとしてはこれ同様の配置で

【読み方|優先度】【昇順|降順】

をそれぞれselectで行う認識であってますかね？

---

追加ボタン

了解です。
こちら @takusea さんのリアクション少し待ちますね。

---

単語辞書ってVOICEVOXやvoicepeakみたくリストと単語編集を同じ画面でできた方が嬉しいですか･･･？

実は自分辞書ほぼ弄って使ってないので、サンプルとしては微妙なのですが、
単純にここ弄った感想して言うと、そもそも同ウィンドウ、かつ普通のリストになっているのが珍しいというか、そうなんだ？という感じではありました。（ボイスピも同様にこの路線なんだなとびっくりしてました）

これについてはそもそも自分がSpreadSheetのようなテーブルが好きというのもありますが、テーブル＆ウィンドウ分離のが良さそうかなと思った理由はこの辺でしょうか

• 仰るとおり画面を広く使え、デザイン的に自由度、拡張性が高い。
• VOICEVOXは現状マルチウィンドウ環境（Windows, Mac）での使用のみを考えている都合、スマホやタブレットアプリのように1画面に収める必要性がない。
• ソート機能の位置がユーザ側も直感的にわかる（ヘッダーをクリック）
• 各種拡張機能の実装も、組み込みコンポーネントのテーブルについているものを使えば良さそうな場合が多い（今回はQuasarを割と多用しているPJなので、QTableが使えそう）
• Windowsの辞書登録的な意味でいうと、Microsoft IME、Google IMEともにテーブルベースのUI（Microsoft IMEはテーブルと別ウィンドウ式、GoogleIMEはウィンドウが同じだがテーブルにそのまま書き込むスプレッドシート式）

例: Microsoft IME

例: Google IME

という感じで、個人的には今のリストを拡張するより、後々色々パラメータが増えたときに対応するための拡張性保持、ソートや検索など機能増やす制作側のコスト、ユーザー側がありそうな機能の脳内補完の面で、自分が作るならテーブルタイプかな？という感じでした。

実際、今回の実装をリストに対してしていて、これQuasarのQTableがそのままつかえるなら機能追加楽だったのでは？と思うシーンがかなりありました。
実際にVOICEVOXのアプリで内部実装しているのがそのまま移植できるかは未確認ですが、今回別途実装したソート、検索はQtable側の機能で全部実装自体はあります。
なんなら優先度をテーブル上で編集できたり、ページング機能ついてたり、遅延読み込みついてたり、かなり高機能だったため、仮にテーブル使うならありかな？とは感じました。

前者はいろんな単語をテキパキ編集できる一方でUIの面積が狭いからデザイン的な制約が高く、後者は一覧性が高いけど単語編集するためにやらないといけない操作が多いんですよね～～～

これですが、テーブルタイプでやらないといけない操作を減らしている例としては、触った感じMicrosoft IMEの辞書と、Quasar QTableだと思います。

Microsoft IMEの辞書登録はスクショの通りテーブルがあるウィンドウと登録用のウィンドウが別に表示されるのですが、登録、編集してもウィンドウが消えない仕組みになっています。
新規登録の場合は登録ボタン押すと中身がクリアされそのまま別の単語入力可能に、編集の場合はテーブルダブルクリックするたびにウィンドウそのまま編集ウィンドウの中身が変わってウィンドウ自体は新たに開いたり閉じたりしないみたいな仕組みになってます。
これは実際Windows IME触るとわかりやすいかなと思います。
感覚的には今右側に写っている編集画面が別ウィンドウになっていて、そのままそれが維持されたまま新規登録・編集できる感じでしょうか。新規ウィンドウで色々対応するなら割とこれ目指しても良い気はします。

例:
https://github.com/user-attachments/assets/e2af3d46-3848-4aef-a702-f1ea7c293bd6

それと、Qtableの方に値編集機能あるので、これも使える気はします。
優先度みたいな簡単な機能や、読みに誤字があった場合のリカバリなどはこれでサクッと行えそうです。
https://quasar.dev/vue-components/table#popup-editing

[takusea]

@takusea すみませんちょっと確認なのですが、プラスボタンってどこに配置する方針になってましたっけ。。
多分2択だったと思ってて、リストの一番下に「追加」ボタンを置いてもOK？あるいはメニューのとこにプラスボタン･･･？
（マルチエンジンでエンジンを追加するときは確かメニューにプラスボタンだった記憶があります。これが暫定処置だったかどうか忘れました。。）

エンジン管理のダイアログでは上部のメニュー部にプラスボタンで実装しましたが、これは辞書ダイアログのもとの追加ボタンの位置と合わせる意図での配置でした！
個人的には似たレイアウトのUIが微妙に配置が違ってユーザーが戸惑うなどが無いよう、両ダイアログで配置が統一されているのが大事だと思うので、（現行のレイアウトではなくテーブル的なレイアウトに根本的に変える場合は別ですが）上部下部どちらに置くかなどこちら側で最適と判断された方にエンジン側のダイアログも追従すればOKだと思います！

[Hiroshiba]

詳しくありがとうございます！！！！！！

あれ、プルリクの段階のもので、それと同じ事やっていないでしょうか？
こっちは昇順降順切り替えが矢印アイコンなので、ベースとしてはこれ同様の配置で
【読み方|優先度】【昇順|降順】
をそれぞれselectで行う認識であってますかね？

あっちょっと違うのを想定してました！
「読み方|優先度　｜　昇順|降順」みたいに4つメニューアイテムが並んでいて、前2つと後ろ2つでセレクターが分かれてるみたいなニュアンスでした！
（これがいいかどうかは結構微妙かもですが、メニューを開く前の面積を小さくできるので。。）

---

テーブルUIの実例、詳しくありがとうございます！！！
確かに単語数が多くなってきたり、要素数が多くなってくると、管理する上ではテーブル UI の方が圧倒的に良さそうだなと直感しました！！

ただよくよく考えると、大多数の人はそもそも単語辞書ってほとんどが追加操作で、編集することはめったになく（読みが変わることはない、優先度を変えたい時くらい）、削除はほとんどしない気がします。
編集する対象は、あまり出てこない単語の優先度を上げ、逆に出やすい単語の優先度を下げるくらい？
ただ辞書を作ることが目的の人はテーブルの方が良さそう。一括設定とかもできそうなので。

ざっと見積もって単語を20個以上登録する人にとってはテーブルの方が良い、それ未満の人にとってはデザイン的にリストの方がまだ良い、って感じですかねぇ！！
あと後述の理由で結構完全テーブル化は難度が高く実現性が難しいから、一旦今のリスト方をよりよくするか、リストのところをテーブルにしちゃうかがアリかも。

ウィンドウを分ける

これElectron特有の問題があって、ウィンドウが分かれるとプロセスが分かれるんですよねー。
なので密に連携しようとすると実装が途端に難しくなります。。
あとブラウザ展開とかスマホ展開とかが難しくなるので結構避けたいかもです！
左にテーブル、右に詳細モーダル、みたいなのは問題ないかと！（今の UI の左のリストをテーブルにする感じ）

QTable

デザインフレームワークにあまり依存しすぎない形にしたく、QTableの機能に依存しまくるのは避けたい気持ちが少しあります！
力を借りるのはいいと思うので、もし実装するなら特殊すぎない実装を目指したい！
確か「キー割り当てダイアログ」はQTableを使っていたはず･･･？

あと仮にテーブルにしたとしても、アクセント調整と音声の試聴だけは別 UI が必要なので、その辺どうするか考える必要がありそうです。
ということがあって完全にテーブルのみにするのは実装難度（と手間）が高めだと思ってます！

---

@takusea さんもありがとうございます！
あとソングの方のトラック追加もメニューのところに追加ボタンだったりします。
トークのメイン画面のテキスト欄追加だけ、右下にフローティングボタン。（これはメニューがないので仕方ないですが）

とりあえずメニューに追加ボタンを置く形が良いのかなと思いました！！

---

ボタンの位置はメニュー欄として、今までの議論から、左のリスト欄をもっと横幅広くして、テーブルにしてしまうのもありだと思います！
こうするとソートUIの表示方法もいい感じできるし、横幅が広くなるので検索メニューもより良い場所に移動できる気がします。

もし @kebin628 さん的にモチベがあれば、一旦 テーブルバージョンも作ってみるとかどうでしょうか･･･！
あるいは一旦リスト＋メニューに色々ボタン追加を実装してしまうのもありだと思います！
ただリストの場合はソート用のUIは特別に作る必要があるので、将来テーブルに変えるなら結構な二度手間かもです。
個人的には･･････一旦テーブルUIにしてみた時どういう見た目になるかのモック画像を作ってみるとかが良いかもです！！！