堕天使の煉獄

ガリガリPG。
ファイル検索のFileSeeker3というツールの代替ツール。

検索対象のフォルダリストに対して、複数選択→移動（並び替え変更）みたいな処理書いてた時のこと。

選択中のindexリスト(ソート済み)で、移動先の位置rowに、要はカット＆ペーストするわけで。

それをQListだと、どう処理したものかなと。
リストの途中に別のリストを挿入するシンプルな方法がどうも無いっぽいんですよね。

色々ぐぐってたら、std::listにはspliceというメソッドがあって、それで実現できそうぽ。
うーん。
QListでsplice的なことやる方法ないのかなともっかいググったらば。

◆AI による概要

てところで、QListでsplice使ってるコード例が出てくる。

あるぇ？
QListにsplice在るの？？

たまたま見てたのが古いverのドキュメントで、新しいverでは追加されてるとか？
と、Qtのドキュメント最新なのを確認してみたら、やっぱり無い……。

ああ、AIが嘘ついてるパターンか……ってなってしょんぼり。

最近AI流行りだけど、こういうのあるから信用出来ないんだよな。

AIでプログラマの仕事がなくなります！　とか言うけど、何処でどんなバグが混入してるのかわからない、かえって厄介なコードになりそうな予感バリバリなんですけどね。
大規模なのとかだと。

ぱっとみて精査できる量のものを、いちいち手で打ったりする手間軽減のためってのなら良さげだけどさ。

まあ、まだまだ過渡期なのでなんとも言えない部分ではあるけどね。


あとちょっと話しずれるけど、最近ますますQt関係でググると、Python版のQtの記事に当たる率が上がってて邪魔くさい。

ほぼc++のコードに置き換えられるので、まったく参考にならないってことはないんだけども。
いちいち置き換えが必要になるので、面倒くさい。

Pythonなんて大っ嫌いだっ！！

てか結構、好き嫌いきっぱり別れてるみたいねPython。



話は変わって、とりあえず検索できるところまで進んだのですが。

んんー。

数百、数千程度なら一瞬とか数秒ぐらいで検索終わるけど、D:\とかE:\みたいなドライブ全体で、数万、数十万とファイルやフォルダある感じな場所指定すると、数十秒待たされるぽ。

少ない数ならそこそこ高速。
大量にあると、実用に耐えないレベルな感じに。
まあそれでもそこそこ速いのでMFT使って検索してるっぽい感じっぽい？　多分。

んー用途的に、まずタブで検索分類を分けられて（画像、音楽、テキスト...みたいな）
さらには細かく検索場所を指定して、検索場所も検索のon/offなんかをぺぺいとできる感じにはなってるので、検索場所登録時にある程度場所は絞れるわけで。
例えば画像なら、この辺のフォルダにまとめてあるとか、多少はそういう運用してるだろうし。

なので、もともとドライブ全体の検索みたいな用途は向き不向きの問題として切り捨てて、せいぜい数千～数万程度の検索にしか使わないのを前提としたツールです！
と言い切ってしまう方向もありなんじゃないかなーとかｗ

ドライブ全体検索とか、そういうのはEverythingとか使えばいいじゃないっていう。


んで、検索場所登録方式だと、インデックス作成するのも、そのインデックスのデータがバラける感じになりそうなので、あんま向いてない感じかなぁと。

サブフォルダも登録出来てしまうので、場所がダブったりもするし。
一応検索場所のダブりは弾く作りにはなってるんだけども、上の方にある登録フォルダの、サブディレクトリも検索対象にするフラグのオンオフで、切り替えとかあるので、検索場所のインデックスが一意なものになりにくいんですよね。
そういう意味で、バラけちゃう感じぽ。


なにげにこの辺ちょっと調べてた時に、QFileSystemWatcherなるものみつけて、へぇーファイルやフォルダに変更あったのを監視して通知するやつあるんだーと。
QFileSystemModelなんかでも、これが内部で使われてる感じっぽい？

となると、別スレッドで動いてて、ファイルのロックとかしちゃうとなると、ちょっと使い勝手わるそうかなぁ。
用途にも依るんだろうけど。

そしてこれも、複数のフォルダを登録して～てのだと、その登録フォルダ毎にQFileSystemWatcherを設置することになって、その都度スレッド立ち上げる感じになっちゃうっぽいので、なんかこれも向いてない気がする。
これ大量に設置とかするとパフォーマンスどうなんだろ？

QFileSystemWatcher Class
ttps://runebook.dev/ja/docs/qt/qfilesystemwatcher

ファイルやディレクトリの変更を監視する行為は、システム リソースを消費します。つまり、プロセスが同時に監視できるファイルとディレクトリの数には制限があります。たとえば、すべての BSD バリアントでは、監視対象ファイルごとに開いているファイル記述子が必要です。一部のシステムでは、開いているファイル記述子の数がデフォルトで 256 に制限されています

監視できる数に制限あるみたいね。
一個のフォルダツリーを監視するぐらいならいいけど(ファイラー的なの)、このツールみたいに、登録したパス毎に監視を……てのは避けたほうが良さそうね。


んーそうか。
そういう問題があるから、場所を登録してのファイル検索ソフトってFileSeeker以外には世に全然出てないんかなぁ。
とか思ったり。

FileSeekerとか、独自方式のインデックス作成してるみたいなこと謳ってたけど、これ結構かなり中身複雑なんじゃないのかなぁ。
サブフォルダとか有効無効の指定周りでなんか動かないバグあるのもそのへんの複雑さ故な気がしてたり。
インデックスの作成速度に検索速度に、その辺りはすごく優秀なソフトなんだなぁと再認識。
せめて検索ワードの履歴だけでも出てくれればあとは我慢して使うのになぁ……。


……つまるところ、この検索場所登録方のファイル検索ソフトでは、インデックス方式はなかなか厳しい……ていうのが現時点での感想だったり。

上にも書いたように、フォルダ登録の時点で、なるべく検索対象のファイル数を絞るような登録＆ジャンル分けをして運用する。
インデックスは作成しない（結果のキャッシュぐらいはする）っていう方向にしようかなぁ。

検索自体は別スレッドにして、長くかかる場合は途中でリセットかけられる感じにして。

よく使う場所でさっと検索したいみたいな用途向けに特化した感じに舵をきるのがいいのかなぁと。

んで、大規模に検索したいときは他のツール使えばいいじゃないって感じでｗ

むうん。