堕天使の煉獄

FileSeeker3の代替ツール開発。

ようやく検索周りに取り掛かったところで、次から次へと問題というか、考慮するべき問題が噴出して、あまりの物量というか考えなきゃいけない事の多さに一旦現実逃避してました（ぉ



とりあえず検索まで出来た～。

まず検索対象フォルダの方、最初はQListViewを使ってたのだけども、model/view構造だと、D&Dでの移動がなんか上手くいかない。
まあ登録パスだけなので数ないし、D&Dの移動が簡単なQListWidgetに切り替えるか。
出来た～。
んんん……複数選択してのD&Dでの移動、移動先のindexに移動元のindexListのアイテムを移動。
QListだとどうやるんだ？？
泥臭くちまちまやる以外になんか機能として無いのかなそういうの。
……またgoogle先生のAIが有りもしない関数使ってるコード吐いてて、ねえじゃんそんなメンバ関数……嘘吐きぃぃ！
ってなったりｗ
この流れ何度目って感じぽ。


ん～でもやっぱ、階層の深さ指定出来るんなら、サブフォルダ表示ある方が捗るかなぁ。
じゃあQTreeWidgetに変更するか。

なんか挙動がQListWidgetと色々違う。
チェックボックス付けるとItemフラグが選択可能だのなんだの、Treeアイテム固有の設定が色々あって、複数選択周りの挙動がQListWidgetと全然違う。

あとD&D移動は一番親のアイテムのみ可能で、下位フォルダは移動不可というかD&Dも不可にしたい。
チェックボックスのon・offでの下位フォルダの扱いとか、下位フォルダはツリーの開閉時に取得する形にしたほうがいい（先に一旦取得しておく形だと、フォルダ構成が外部で変更時に自動で変更しないので面倒）

などなど、次から次へと、考慮すべき問題が出てきて、ここだけでもえらく時間食ったり。
Qtって、ちょっと変わった独自の動作とかさせようと思うと途端にいろいろと面倒になるんだよなｗ
コーディングの時間よりもドキュメント調べてる時間のほうが遥かに長い……。

D&Dでもドロップ位置が、アイテム上なら位置入れ替え(swap)、アイテムの上の位置、下の位置（微妙によく見るとアイテムとアイテムの間に2つドロップ位置がある）で、上から下にD&Dした場合と、その逆で動作が変わったりするのとかも地味に面倒だったりするし。


で、そこからようやく検索周りに。

QFileSystemWatcherで検索対象フォルダパスの構成に外部で変更あればリストを更新。
QFutureWatcherで別スレッドで検索実行。

結果のキャッシュとか、検索対象フォルダパスに変更あった時に、どのタイミングで再作成するかとか、タブを切り替えた時にどのキャッシュを残したままにするのかとか。

また、QFileSystemWatcherで監視できるパスの数はOS依存で決まっているらしいので、現在のタブ内の登録検索対象フォルダパスのみ監視対象にしているので、タブを切り替えて戻ってくるまでの間にファイル構成に変更あったときはどうすんの？
とか。

とにかく色々と考慮すべき事がいぱーい。
そりゃ、検索対象をタブで分けて管理とか出来るファイル検索ソフトとかみたことねーわ。
それ起因の面倒がかなり多い印象だったりして。
むううん。


FileSeeker3では経過時間でも一定間隔空くとキャッシュをクリアしてるっぽい？

検索結果というか、検索対象のファイルリストのキャッシュ（インデックス作成）もしてるっぽいんだけど、同じ検索対象フォルダパス群に対して別の検索ワードで検索すると、一瞬で結果表示できるのはオンメモリのファイルリストに対して検索を行ってるからっぽいよね。

同一タブ内で別のワードで再検索する場合には高速で結果でていいんだけども、ファイル構成変更あった場合、変更のあったパスのところだけインデックス再取得＆再検索とかになるのか？
そうなるとインデックスはパス毎に別れてて欲しいけど……。

今作ってるのは、タブで検索対象の分類を分けれるのが特色の一つなので、つまるところ検索対象をもともとかなり絞る作りになっている感じで。
なので、ドライブ指定で以下全検索みたいなのはそもそもやらない＆出来ない（走査するサブディレクトリの階層に制限ある）

なので、インデックス使わないで毎度検索でもそれなりに速度もでるんじゃないかなぁとか思ったり。
検索対象のファイル構成に変更がない場合は、検索結果のキャッシュはしてるので、検索ワードの履歴から何個か前の結果を表示するときはすぐに出る感じにはなってるし。

うーん。
FileSeeker3だと検索後にステータスバーで検索ヒット件数と掛かった秒数が表示されてるので、そこも真似してみる。
んで、大量のファイルのあるフォルダの場合の時間とか見ながらこのへんの、何処にどれだけコストかけたり、キャッシュ効かせたりするのかとか探って行くしかないか。

「最高のテストは実戦」とジオブリ栄子ちゃんも言ってたしな（ぉ


後はちょろっとだけある設定まわり（検索ワード履歴の最高保持件数だとかそんなん）の設定ダイアログと、検索結果リストアイテムの処理周りぐらいかな。

検索結果リストアイテムの処理周りは、コンテキストメニューで「送る」メニューを自前で読み込む方向に舵を切ったんだけども。
そのおかげでwinAPIを直接触らなくても良くなったのだけど。
あとCOMライブラリを初期化＆開放処理もいらない。やったねたえちゃん！

今度はダブルクリックでファイルタイプに関連付けられたアプリで起動……てのがQProcessでは出来ないっぽい？？

結局「ShellExecute」ていうwinAPIを使う羽目に。
COMライブラリを初期化＆開放処理もやっぱり必要になるというオチ。たえちゃんやっぱりバッドエンド！
んーなんとかならんのかこれ。

windows.hをincludeすると、名前空間が大量のゴミであふれるのでやりたくないんですよね……。
windows.hをc++のモジュール化する話はどこいったんだろね(モジュール化することで名前空間の汚染も止められる)
めちゃくちゃに肥大＆依存関係てんてこもり＆影響範囲が大きすぎて怖くて弄れない巨大な負の遺産windows.h……。

したらQDesktopServices::openUrlで出来るのか。
QUrlの指定で「file:///」から初めてファイルパスを書けば規定のアプリで開けるように。
今度こそやったねたえちゃん！
無事にwindows.hのincludeを削除。
はースッキリ。

なんかQFileでもそれ出来るでと例の如くgoogle先生のAIが申しております。

「QFile::open(QIODevice::ReadWrite)の引数でQIODevice::ShowInWindowフラグを使うと、ファイルをデフォルトのアプリケーションで開くことができます」

QIODevice::ShowInWindowフラグでググってもなんにもヒットしねぇ。
どんだけ調べてもQFileにデフォルトのアプリ開く機能ないぞコレ。
またAIの嘘吐きぃ！

真っ先に嘘かも？　と疑う前提でしか見れないAIってもはや害悪だろこれｗ


そんな感じで、FileSeeker3の代替ツール開発、ようやく終わりが見えてきた～。