堕天使の煉獄

今日もニコニコPG

ファイル検索の方のタブ周り、別の同じような内容動作のテキストビューワで使っていた部分を流用していたのだけども、いろいろと組み直していい感じに刷新出来たので、テキストビューワの方にもフィードバック。

ついでにそっちで欲しいなと思ってた、全文検索（grep）を追加。


このツールは、pgのコードをハイライタ付きで表示出来たりもするので、今やってるような、昔組んだやつを新しいプロジェクト作って組み直す……みたいな時に、古いプロジェクトの場所を表示、参照しながらコードの移行とか出来るので重宝しているのですが。

今までは検索は現在開いているファイルのみの検索機能しかなかったので、プロジェクト全体で検索できるといいなぁ。
と思ってたのでタブ周り組み直すついでに追加してみたり。

んでもまあ、Qt Creator見たく、通常検索とgrepを統合したようなuiに出来たらよかったんですけどね。
個別にダイアログだして、普通に行数+ヒットした行をそのまま表示するシンプルなスタイルに。
一応、ヒットした行をダブルクリックで、該当ファイルの該当行に移動＆検索ワードハイライタ辺りは、もともとのテキスト表示部分の既存のメソッドいくつか呼ぶだけで実現出来たので楽だったり。

プロジェクト全体で検索できる（実際にはプロジェクトのある場所をタブに登録して、タブ単位でgrepの対象を指定できる作りになってる）様になったので、これは捗るわ～。


しかし、今回タブ周りも組み直してて思うのが、QtのQTabBarってあんまイケてない実装だなぁと。
かなり昔からあるクラスで、中身殆ど変わってないっぽいのですが、とても使いづらい。
タブに登録した内容のデータにはindex経由でしかアクセス出来ないとか、タブ名とかでループ回して処理するのにも、タブのcount()取得して、インデックスでループ回さないといけなかったりで、どうにもまどろっこしい。

これもmodel/viewな感じで、タブの内容のリストを自分で管理できるといいんですけどね。
なんでそうなってないのかというと、タブをドラッグしたときの挙動とかに問題が出てくるので素直に出来ないっぽいみたいなのを何かで読んだ気がするぽ。


次にやった作業が、検索ツールの方、検索結果の右クリックで、画像のプレビューとかほしいかなと。


普段使ってるファイラーでは、シェル拡張で右クリックメニューに画像プレビュー追加してあるのので、同じ様に使えるといいなぁってことで。

まああんまりファイル名で画像ファイルを検索することは自分的にはあんまりないのですが。
たまに意図せず引っかかってこの画像なんだ？
って時にプレビューで確認出来るのは楽でいいかなと。

これでまあ大体、標準のwinの右クリックメニューの中身で必要なものは自前で置き換えたので、不自由ないかなと思ってたのですが。

標準の右クリックメニューを見てみると、「プロパティ」なる項目が。
あー、権限だとか詳細だとか見られるやつ……。

……調べてみると、コレをQtで表示するのはどうも無理臭いという結論に。

いやまあ、出来なくはないのですが。
WinApiのShellExecuteExを直接呼び出せば(まあ当然だけど)

ただ、それをやってしまうと、せっかくそのへん排除して自前でメニュー作ることでwindows.hのインクルード回避したのに、その努力が水の泡なわけですよ。

最初は色々調べたところで、
QProcessのオプションで「Properties」を選択すれば出せるっぽい雰囲気だったのですが。
QProcess::startDetached("Properties", { filePath });
みたいな感じで。
したら「そんな動作はねぇ！」と実行時エラーで怒られます。

何でもShellExecuteExでもファイルのプロパティを出すためには

SHELLEXECUTEINFO info
...
info.fMask = SEE_MASK_INVOKEIDLIST;

このinfo.fMaskのSEE_MASK_INVOKEIDLIST設定が必要らしいのですが、その項目の設定に対応する方法がQProcessには無いっぽいんですよね。
なので結局自前でShellExecuteExを呼び出す方法でしかwin標準のファイルのプロパティを開く方法はないというのが結論ぽ。

ということで、ファイルのプロパティはもういいかということにｗ
無くても困らんだろ（ぉ


そんな感じで、実践使用してみて、アレが欲しいとかアレがなかったって部分を追加してたり。

それも一段落したので、TODOリスト的には、uLilithフェイスエディタと書庫ファイルの中身いろいろ編集するツールのあと2つとなったので、ようやく先が見えてきた感じぽ。

とっとと終わらせて後顧の憂いを断って、3DダンジョンRPGづくり始めたいですね。
ふい～

FileSeeker3の代替ツール開発。

とりあず完成ぽ。


前回の内容の更新案を色々盛り込んだりして、とりあえずキリのいい感じに放ったかなと。

タブの一時非表示化
親パス毎に掘るサブフォルダ階層個別指定（画像の[無制限]とか[+2]とかがそれ）
全体の検索ワード履歴

あたり。


しかしこのツール、なんか妙に時間がかかってしまったり。

ハマったのが、リスト内アイテムのD&Dでの移動。
え？　そんなん簡単やん。ハマる所ある？
って感じなのですが、以外にハマってしまったり。

ドロップ先の指定にdropIndicatorPositionなるものがあって。

QAbstractItemView::OnItem
QAbstractItemView::AboveItem
QAbstractItemView::BelowItem
QAbstractItemView::OnViewport

の4種類。

「OnItem」はアイテムの上にドロップ。
コレはmoveでなくswap、D&Dでアイテムの入れ替え動作をしたい時に使う感じかな。

「OnViewport」はアイテム上ではないビューポート上。
アイテムのない空白部分へのドロップってことですね。
無視するか、リストの末尾に移動に振り分ける感じか。

で、問題がAboveItemとBelowItem。

AboveItemがインデックスの上にドロップ。
BelowItemがインデックスの下にドロップ。

これが厄介だったりで。
リストアイテムとアイテムの間にD&Dするとき、よく見ると、アイテム間にドロップする場所が2箇所あるんですよね。
んで、AboveItemの場合はインデックスの上。
つまり、ドロップ対象アイテムのindexはドロップ位置の下のアイテムのインデックスに。
BelowItemの場合はドロップ対象アイテムのindexはドロップ位置の上のアイテムのインデックスになる。

通常、アイテムの移動は、QxxxWidgetなんかに標準でついてる機能でやれはこの辺上手くやってくれてる感じで気にしないでよいのですが。

別にデータリストを自前で持ってて、QxxxWidget上でアイテムの移動あったら、移動元と移動先のindexを取得して、データリストを自分で並び替えて、そのあとQxxxWidgetをデータリストを元に更新。

みたいな運用してると、この移動先のindexの取得がAboveItemとBelowItemによってずれるんですよね。

しかも面倒くさいのが、移動先が移動元よりも上にあるか下にあるかでAboveItemとBelowItemが逆動作になったりして。

で、そのへん整理して理解するの面倒くさかったものの、なんとか組み終える。
単アイテムのD&Dは。

問題は、複数行選択時のD&D。
移動開始位置アイテムを基準にすればあとは同じかなとおもったのですが、なんか上手くいかない。
なんか位置がずれる。
しかも2つとかズレたりして、なんかバグってないかコレ？
となって、しばらく考えた後、考えることをやめましたｗ

そもそも複数行選択でD&Dって、いるのかな？
となったりで。

結局複数行選択時は、全部「先頭に移動」か「末尾に移動」というのを追加することに。

そんな感じで、すっげぇめんどくさくて、ひとしきりぐじぐじ弄り倒した挙げ句、いかに楽するかという方向で終わらせる感じにｗ

んでも、普通のwinアプリの他のツール(ファイラー系)なんかで見てみたけど、アイテムとアイテムの間の移動先が2つに別れてるのなんて無いんですが。
普通に真ん中に一個だけしか無い……。

Qtはクロスプラットフォームなので、多分そういうシステムのOSがあるのかな。
それにも対応できるようにそうなってるのかもしれないぽ。



次にハマったのが、検索結果につけた、コンテキストメニュー内の「送る」。
標準のシェル使うと必要になるwindows.hともろもろをインクルードしたくないので、自前でsendToの中身を拾ってきて表示する方向でつくってるだけど。
動作的には問題なかったんだけど、表示に違和感が。
なんかメニューのアイコンのサイズが32*32になってるんよね。
他のwin標準の機能つかってるファイラーなんかの送るメニューだと、アイコンは16*16。

んで、QMenu内のアイコンのサイズの指定というのが、どうも普通には出来ないらしい。
なんでもメニュー内のアイコンサイズは、OSのスタイルを参照してるとかで。
なるほど、4ｋとかデカい画面モードなんかだと、動的にアイコンサイズなんかも変更する必要があったりして、それに対応するために、setIconSizeなんかでは設定できなくなってるのね。
そういうシステム寄りの機能ってことなのかQMenuは。

んでぐぐってみると、QProxyStyleでスタイルを上書きしてPM_SmallIconSizeで返す値を設定すればOSのスタイルを部分的に書き換えられるそうな。

……確かにサイズは変えられた。

ただし、デカくするのは出来たんだけど、何故か32*32→16*16と小さくしても32のまま変わらないという。

取得してるアイコン自体に16*16サイズがないのでわ？　そんな馬鹿なと思いながらも、取得したアイコンの内部で持ってるサイズを列挙する関数あるのでやってみると、ちゃんと16*16は含まれている。

んんーなんか何処かでサイズ制限かけられてる感じ？？
雰囲気的にはOSの元のスタイルを反映してるっっぽいのでそのへんかと思うものの、じゃあ普通に使ってるファイラーの「送る」のアイコンは16*16になってるよ？　ってなるし。

全くわからん……。

とりあえず、アイコンを一旦pixmapに出力して、サイズを16*16にした後、そのpixmapをアイコンとして登録(16*16しか存在しないアイコン)とすると、まあ16*16のアイコンで表示できるようにはなったんだけども……。

これってOSの設定なんかでスケーリングが変更された時でも、ここはハ－ドコーディングされちゃってるので16*16のちっこいアイコンしかでねぇよ？
となっちゃうので、あんまりよろしくない解決法だなぁ……。

この辺、内部でどうなってるのかとか調べてるだけでも数日経ってたりして。
まあ、わからない部分を解明していく過程で色々と知識も蓄えられていくので無駄ではないんですけどもね……それでも時間の浪費と徒労感は積もるわぁ……。


そんで最後のハマりポイントは、検索対象のパスとかファイルリストの管理方法、いつ何処で何をキャッシュするかとかそのへん。

この辺は結局いまだにどうするのがベストなのかまだ全然結論出てません。

タブ毎で検索対象パスリストを切り替える方式というのが問題を複雑にしてる感あったりもするのですがｗ

そこで、検索対象パスリスト自体はアプリ全体で一個共通で持つ……という方向にしたほうが管理は楽なのですが、無駄が多かったり、無駄を省こうと思うと結局複雑な感じになりそうだし……。

そんな感じで、スッキリしないモヤモヤな感じに。


んまあ、とりあえずここらでキリつけて次に進みたいかなと言う感じぽ。
しばらくは運用してみて使用感を確かめて……結局FileSeeker3でいいかってなるオチもあるんだけどね（ぉ

はふ～

むーん
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が難しすぎてどうすんべって感じだったのが、今ならなんとか組めそうって感じで得るものは十分あったんですけどね。


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

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の代替ツール開発、ようやく終わりが見えてきた～。

相変わらずPG。
といいつつ、ちょっとモチベーション切れ起こして、すこし気分転換でゲームやったりしてましたけど。

FileSeeker3の代替ツール開発。

検索結果のキャッシュやら、あとQFileSystemWatcherをちゃんと調べ始めたら、思ってた感じと違ってたなーって感じで、そのへん含めて、データ構造周りからかなり組み直してたりして。

QFileSystemWatcherはなんか、OSの機能を使ってるっぽい。
なので、監視できる数の上限制約の数も環境依存みたいなのですが。

監視パスを登録する時にその制約に引っかかったりして登録できなかった場合には、登録漏れしたパスが返ってくる感じで、エラーコード的なもの（どういう理由で登録できなかったのか）は一切ない感じで。

あと、このツールの用途的に、タブが切り替わったらこの監視パスも全部タブ別に登録されたパスリストに切り替える必要あるんだけども、登録パスを一括で解除する機能がないぽ。

QStringList QFileSystemWatcher::removePaths(const QStringList &paths)

に

QStringList QFileSystemWatcher::directories() const

で取得した、現在登録中のパスを渡す。

m_fsw->removePaths(m_fsw->directories());

とする方法を取るようなんだけども。

中身これだけなら、clear()とかのメソッド欲しいなとか思ったり。
なんでないんだろ？？

あとQFileSystemWatcher調べ始めたところ、なんかQFileSystemWatcherは古いAPIで「deprecated」だ見たいな記事出てきて。
内部のコードに問題があるため、新APIに切り替わる予定みたいなことも書かれてたりで、えぇー！？（マスオ調）ってなったのですが、その記事のタイムスタンプみたら２０１１年で、あるぇー？　ってなったり。

それ以降はそんな話も出てこないし、最新のQFileSystemWatcherのドキュメントにもそんな事書かれてないし……どゆこと？

でもclear()が無かったり、なんかえらく簡素な作りになってるな感あったんですよね。
なんかそのうち書き直すつもりで、その時に利用コードに影響与えにくいように機能絞ってたりとか？

エラーコードとかなかったり、色々となんか足りてない感。
とりあえず必要最小限の機能だけつけときました。無くちゃ困るから。
って感じの雰囲気。

あと、これ単体では、OSの機能使ってるっぽいので、別スレッドで～みたいなことはしてないのかな。OS依存？
雰囲気的に、OSのイベントログあたりを監視してる感じっぽいんだけども。
でもそれだとファイルロックはしないよなぁ。
んー中身が不透明すぎてよくわからんQFileSystemWatcher。
というかQFileSystemModel。

んで、検索結果のキャッシュと、検索対象のインデックス作成周り。

ネックになるのはサブディレクトリ関連で。

現状、サブディレクトリを読み込むかどうかのフラグを、登録パス毎にもたせてて。
で、検索前に登録パスが他の登録パスのサブディレクトリだったりするケースもあるので、重複しない一意なパスリストをまず作成してから、パス毎にファイルリストを取得してキャッシュ。
QFileSystemWatcherでdirectoryChangedシグナルきたら、該当パスのところだけリスト再取得してインデックス更新～みたいな流れなのだけども。

んーやっぱサブディレクトリ含むと数が膨大になりがちで、いっそのことサブディレクトリは読み込まない作りにしちゃうか。

登録パスリスト内で、右クリック→サブディレクトリのパスをすべて登録(1階層)ていうコマンド作ってあるのだけども。

ん～。

なんてことを、先程急にもよおしたのでトイレでクロワッサンを製造してたらば。

ああ、読み込むサブディレクトリの階層数を指定して制限するのがいいのでわ。

と閃いたり。

寝る前とか、トイレで踏ん張ってる時って、なんか色々と閃くよねｗ

そしたら、ルートディレクトリなんか指定して、数万とかのインデックス作成で激重みたいなのも避けられるし、数階層下のものをまとめて検索対象にしたいだけなのに、いちいち全部パスを登録するのも手間。
っていう問題も両方解決するなと。

なにげに、ウェブページのダウンロードツールなんかで、走査する階層の制限指定とかあるよねーてのがどういう経路からか浮かんで、そうかそんな感じにすればいいのかみたいな感じだったのですが。

ウェブページのダウンロードツールなんてのももう何年も使った覚えがない（個人サイトがほぼ死滅してるしね昨今）のに、どっから降っってきたのやらｗ
その手のツールだと、大体その設定では階層指定を無制限する設定もあったりするのですが、そのへんの概念がふと脳みその中で結びついたのかな。

そんな感じで、そのへんのデータ構造やらいろいろと組み直し中ぽ。



話は変わって。

WILDERNESS(ワイルダネス) 完結の9巻 2025/10/17に発売予定。

ワイルダネスは完結までやる。
という作者さんのお言葉通り、完結まで行ってくれたんだなと。

病気で利き腕変更乗り越えての完結。
お布施の意味でも買わねば。

てみたら定価 814円て書いてあってびっくり。
B6サイズもはや昔の大判サイズと値段変わらなくなってきたね。
昔はこのサイズの本は500円のイメージなのでどんどん値上がりしてるなぁと。

最近めっきり紙の本なんて買ってないので、前回買ったのはブラックラグーンの新刊なのですが。あれも700円代半ばとか後半だった気がする。
最近の物価高半端ねぇな。

でもワイルダネス最終巻、ページ数が208頁と結構多めのページ数なので、その分値段上がってるだけなのかも。

……ジオブリもいつかは再開……するのかなぁ。