堕天使の煉獄

むーん
FileSeeker3の代替ツール開発。

とりあえず現状、最低限の機能は揃ったβ版と言った所。

んで、「最高のテストは実戦」ということで、実際にいろいろとパスを登録して使ってみるテスト。

……うーんやっぱ色々と、ここはこうすればとかこういう機能欲しかったなとかがポコポコと。


■タブ
数が増えるとちょっと邪魔くさい。
そして数が増えるとタブ1つあたりの幅が狭くなるので、タブの閉じるボタン[☓]が誤作動しがち。
一応閉じるかダイアログで確認でるから、意図せず消しちゃったってことにはなりにくいけど、誤操作でいちいちダイアログ出るのも邪魔くさい。
タブの閉じるボタンは非表示オプション要るなこれ。

そして、タブ内での検索対象ファイルパスの登録、結構数がおおくなってメンドイので一度やったらもう糖分触りたくないｗ
が、そんなに使う機会のないタブは邪魔な感じも。
でもタブ消すと登録リストも全部消えちゃうので、再登録は面倒くさい。
……タブを一時的に非表示にして隠す機能とか欲しいかな。
もしくはインポート・エクスポートで外部に保存とか。


■検索対象パスツリー
現状、走査するサブフォルダ階層の制限をタブ単位で設定しているのだけども。
実際に運用してみると、やっぱ各親パス毎に設定欲しいなと。

たとえば、ブラウザの保存場所に指定してあるフォルダなんかだと、その下に結構アドオンがフォルダとかぽこぽこ作ってたり、無駄に検索パスが増えてる感じで、ここはサブフォルダ掘らない様にしたいなぁとか。

ただそのへん、ツリー上の表示をどうするかって所が悩みどころ。

FileSeeker3だと、チェックボックスと、選択状態（ハイライト）の二種で有効・無効サブディレクトリ読み込みon・offとかになってるんだけども。

サブフォルダにもチェックボックスついてて、そこで検索のon・off切り替えられるのはまあ便利だな（むしろ上記のケースだと欲しい機能ｗ）とは思うものの、
サブフォルダのチェック状態を設定ファイルに保存する必要が出てくるのだけども、サブフォルダは構成変わった時どうするのか。
そのへんの扱いが面倒なんですよね。
なのでサブフォルダの個別on・offはやりたくない感じぽ。

なので、親パスに掘る階層を設定出来るようにして、かつ無制限に掘る設定も指定できると良い感じかなぁ。
基本、サブディレクトリも別の親パスとして登録出来るので、ずらーっと用のないサブフォルダならんでる中で、ここだけは検索対象に入れたいってときはそのパスを親パスとして新規で登録すればいいだけだし。

んで、ツリーの表示上は……
名前の前か後ろに掘る回数を表示する感じかなぁ。無制限だとなんか記号的なので。
で、指定なし＝大元の設定参照な感じで。

うーん。
ツリービューのアイテムって表示周りで弄れる所というか、幅が狭いんだよなぁ。
とりあえずやってみるか……。


■検索ワード
タブ切り替え時、履歴の先頭を呼び出す（オプションにする？）
んで、その検索ワードにキャッシュがあれば結果リストに表示。

検索ワードの履歴はタブ毎に保存されてるので、切り替える時の処理のことあんまり考えられてなかったなと。
やっぱこういうのは実際に運用してみないと判らない部分だなぁ。

似たようなジャンルだけとタブで分けられてる時、同じワードで検索したい……ってケースも多いので、タブ毎とは別に、全体の検索ワード履歴も欲しいかなと思ったり。

検索ワードにはブックマーク機能もつけてるんだけども、全体履歴にも～とかどんどん設定項目が増えていくなぁｗ



んで。

実際にちょっと運用してみて、ポコポコ出てきたTODOを書き出したのだけども。

そもそも根本的に、このツール使えるのか？　という問題が。
大量（数千程度？）の検索対象のある場所で大量にヒットする感じの検索をやってみた結果。

FileSeeker3だと0.2秒ぐらい。

自作ツールだと0.6秒ぐらい。（キャッシュ一切不使用状態）

結構遅い。

ただ、FileSeeker3の方は検索対象パスのキャッシュが効いてるっぽい？　とか
時間の計測が、自作ツールの方は、検索スレッド立てる直前から計測開始してるので、スレッド立ち上げる時間も含まれてるので、きちんと比較が取れてる訳では無い感じではあるのだけども。

自作ツールでは検索対象をジャンル分けしてる分、検索対象パスの数はかなり少なくなってるはずなんだけど、その点で検索スピードが増してるかというと、とにかくなんもかんも検索対象パスをぶっこんでるFileSeeker3とそこまで速度差がないどころか、体感的に普通にFileSeeker3のが速いなコレ。

ってなってるんですよね。

FileSeeker3はEverythingのソースを参考にしてるとかなんかで見たことあるので、やっぱ速えなぁと。

あっちはインデックスをDB化して持ってる感じなので、まあ単純にファイルシステム使って検索するよりはそりゃ速いよなと。
ただ、インデックス作成の負荷とか、関係ないところまで検索しまくるので、ちょっと無駄が多い感じあるので、検索場所を制限してタブでそれらを切り替えて、少ない範囲を検索するだけなら低負荷高速で検索できるんじゃないか……ってのと、FileSeeker3はほんと……検索ワードの履歴が使えない一点で、ずーっとそこが不便だってことで今のツール作ってたりするのですが。

Qtのファイル検索はMFT参照してるらしいので、少ない対象だとインデックスなしでも確かに高速だし、まあこれでもいい感じかなぁと思ったんだけども……。
やっぱ数千、数万ある対象から検索しだすと、事前にインデックス作成してない検索だとやっぱちょっと遅くなるなぁと。

んー検索ワードをジャンル別で履歴残せたり、細かく検索対象を分けられたり、利便性ました反面、煩雑な部分も増えたし、そして肝心の検索速度は……遅すぎるってことはないけど、やっぱそれ専用のソフトに比べると、ちょと見劣りするなぁって感じで。

このまま開発続けるか？
お蔵にしちゃう？

とか考えがよぎったり。

まあ、今回やっとQTreeViewの使い方とかまともに出来てきたし（qfilesystemmodelを設置するだけの簡単なサンプルしかなくて、突っ込んだ使い方になると全然参考になる記事とかなくて何がなんやらだったのよね）

この後の予定の、書庫ファイルの中身をなんやらするツールも、書庫の中身を表示するリスト、以前は普通にQTableWidget使ってたんだけど、やっぱ階層表示も欲しいよねってのと、それなりに数おおいから、QxxxWidget系じゃなくてQxxxView系(model/view)使いたいよねと思ってたんだけども、QTreeViewが難しすぎてどうすんべって感じだったのが、今ならなんとか組めそうって感じで得るものは十分あったんですけどね。


ふむう。
もうちょっと運用してみてから考えるかなぁ……。