堕天使の煉獄

とりあえず、ここに進捗書くことで、ここに書くために作業進めないと……となってモチベ維持な目論見中。



検索結果の項目の右クリックメニューで、win標準のContextMenu表示でけた～
まあ、某所で紹介されてたコードほとんど丸写しなのでアレですけど。

んでもまあ……普段、ファイラーはwin標準じゃないやつ使っているので、win標準のContextMenu見るのも久しぶりなわけですが。

使ってるファイラーは、標準のから項目を除外できるような機能あって、邪魔なの排除してスッキリさせてるだけだったかも。
相当昔に設定して以来触ってないのでうろ覚えｗ

で、なんにも触ってない素のメニュー、色々ごちゃごちゃ多すぎｗ
すっげぇ邪魔ｗ

なのでこれ、余計なの削除とかしたいなぁ。

基本的には「開く」と「送る」そして、「リネーム」と「削除」、オマケで「プロパティ」ぐらいあれば十分なんだよな。
別にファイラーじゃないんだし。


でも、上記のだと、「送る」以外はQtの機能でも代用出来るんですよね。
要るのは「送る」だけな感じぽ。
つまるところ、「送る」が欲しいので標準のメニューを呼び出してるわけです。
FileSeeker3使ってるときでも、「送る」はよく使ってたし。

でもこれ、Qtのウィンドウじゃなくて、Win32API製のWindowを作って表示させてるので、「送る」だけをQtのContextMenuに持ってきて表示みたいなのは出来ないっぽいんですよね。

んーSendToのメニューだけを呼び出す方法がなんかあるっぽいような感じもある。
なんか中国語のサイトで登録しないと続き見れないよっていう残念なところで、もろそれっぽいの出てきたんだけど。

他の案としては
WindowsShellはもう使わないでSendToのなかのショートカットのリストを取得して、そこからパス渡して別プロセスで起動……みたいなのを自前でやるとか？


もうちょっと調査してみるか。


あー「開く」でも二種類あるんだよなFileSeeker3の方のメニューだと。

・ファイルを規定のアプリで開く
・ファイルの場所をエクスプローラで開く

の二種。

標準のメニューだとOpenて書かれてるやつは、多分前者。
後者のはFileSeeker3では独自に追加してるものっぽい。
でも、FileSeeker3でも、後者の方の開くだと、win標準のエクスプローラが開いちゃうので超うぜぇｗ

win標準のエクスプローラが性能的にひどいから別のファイラー使ってるので、いまさら見たくもないんですよね。

そうなると、ファイルのパスもしくはファイルの場所のディレクトリのパスをコピー出来て、普段使ってるファイラーのアドレス欄にコピペ……みたいなのほうが使えるかも。

検索結果の場所のフォルダをファイラーで開きたいって事は結構あるので。

今までは、やむなくwin標準のエクスプローラで開いてそこでパスのコピーしてたんだけど……あれ、今見たらFileSeeker3、検索結果のファイルのメニューに

「一つ上のフォルダを開く」
「フルパスをコピー」

って項目あるじゃん！

結構長く使ってるのに、今気づいたｗ

そんな便利なものwindowsの機能に無いだろと端から意識の外にあって見落としてたっぽいｗ

よくよくみてみると、FileSeeker3は標準のメニューに色々追加してたり除外されてたり結構いじってあるんだな。
スッキリと必要なものだけある感じで。
めっさ理想的なかんじ。
そうか、FileSeeker3は.net製なので、win標準のメニューの拡張もやりやすいのか。
Qtは外部から利用する感じなので、簡単に一部を掠め取ったり出来ないんだよね。

この辺ももうちょっとしらべてみないとな。
結構使い勝手に影響する部分なので。

しかし……ほんと標準のメニューは邪魔なの多すぎｗ
これがwin11になると更に使いにくなるとか言うし。
ほんとMSさんはセンス皆無だなぁ……。

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


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

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

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

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

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

むうん。

久しぶりにPGガリゴリ
まず脳みそをPG用に切り替えるところから始めないとなので、かなりよちよち歩きな感じで再開ｗ

中断前はなにやってたかというと、ファイル検索のFileSeeker3というツールの代替ツール作ってたんだっけか。

UI周り作って、データ構造つくって、実際にUIにデータ流し始めながらテスト～の辺りで止まってたり。

なんかそこで詰まってた記憶あるんだけど、何に悩んでたのかをまず思い出すところからスタートｗ

もうひと月も間空いたc++のコードなんて、もはや他人が描いたコードレベルで覚えてねぇので、まずプロジェクト全体を把握し直すところからなんですが、他人のc++のコード（と化したもの）読むのはほんと疲れるぅ。

そんな感じで久しぶりにPGガリゴリ。


そいやsusieの代替の自作画像ビューワも、あとはアプリのアイコン作るだけのところで放置してたっけな。
今回の夏コミ原稿の資料表示は結局マンガミーヤとRapture（画面の範囲指定プリスクソフト）のあわせ技で結局乗り切ったっけか。
お絵かきの資料集めたフォルダ内の画像を表示みたいな用途も考えて作ったビューワなので、実戦投入しようと思ってたんだけど、もう作業始めちゃったしまた次回でいいかって見送っちゃったんですよね。

アプリのアイコンぐらいさっさと作れやって感じなんですけどねｗ
オンラインで画像ぶっこむだけでファイルアイコン生成してくれるところとか有るんだけども。
でも何を使ったもんやらって感じで。
そいやなんか昔、Windowsの画像アイコンがエヴァのパクリみたいな話あったねｗ

Iconfactory「windowsのアイコン」の元ネタ
ttps://www.ffffff.jp/other/00066/index.html


はーとりあえず、色々と溜まってるものを消化してしまいたいのですが。
新たにまた増えたりもしてるんですよね。

とりあえずPGのTODOリスト

・susieの代替の自作画像ビューワ(アプリアイコン作るだけ)
・FileSeeker3の代替ツール(開発中70%ぐらい)
・[new]uLilithフェイスエディタ
・マンガミーヤの代替ツール(64bit、Unicode対応、7zip使用)
・書庫内編集ツールアップデート(64bit化&7zip使用)

一応作っていく予定の順番でつ。

画像ビューワはもうツール自体は完成してるのでいいとして。
FileSeeker3の代替は、まだ肝心の検索の部分のパフォーマンスがどうなるのかなぁというところで、お蔵になる可能性も。
Qtのファイル検索はMFT使ってるので高速だというどっかで聞いた話が本当なのかなぁと。なのでどのくらい速度出るのか未知数だったりする。

んで今回新たに追加されたのが音楽再生ソフトのuLilithのフェイス（外観スキン）の編集ソフト。
まあ今となってはかなり古いツールなので、10年……20年？　前だったら結構他の人にも需要あったかもｗ
で、なんでそんな古いツールの物を？　ってと、普通にこれを超えるようなツール特に無いので、単体の音声ファイルの再生にはこのツール使い続けてるのですが。
普段聴きはDB系のMusicBeeってソフト使ってます。


2000年ちょい過ぎぐらい？　だったかにLilith→uLilithにバージョンアップして。
文字通り、unicode対応版ですね。
で、その時にフェイス周りの使用も刷新されたのですが。
本家で旧Lilith用のフェイスをuLilithにコンバートするツールが配布されてて。
で、当時、自作してた旧Lilith用のフェイスをコンバートしたのを未だに使ってるのですが。
旧Lilith用のフェイスエディタというのがなかなかいい出来だったのですが、たしかCoffeeScriptだっけ？　で作られてて、もう物がないし手に入るのかも、いまのwin環境で動くのかも知らないのですが、まあ、相当古い時代のものですｗ
で、自作フェイス。
uLilithになって仕様が変わった部分やら、新たに追加された機能なんかもあるのですが、旧版からコンバートしただけなので、一部ちょっと表示がおかしな部分残ってたりするのですが。
まあ、そんな気になるものでもないしまあいいかと放置してたのですけども。

今回夏コミ作業中、久しぶりに深夜のバカ力とかuLilithで聴いてたのですが……

……最近、めっさ老眼が進行して、文字が小さすぎて見えねぇｗｗｗｗｗｗｗｗ

ってなったんですよねOTZ

で、いまだに単体の音声ファイルの再生では使ってるツールだし、老眼対応のフェイスとか欲しいなとか思い始めたのですよｗ

なにげに、昔、１０年前ぐらいかな？　にもフェイスエディタ一度作ってみようと思ったことあって。
８割方出来てたのですが、お蔵入りにしたんですよね。
当時作ったのはそのCoffeeScript製の旧Lilith用フェイスエディタを真似て作ってたのですが。
uLilith自体がですね、当時公式の掲示板とかで機能要望とか募っててもりもり更新されてて。
その過程で、割とテキストベースで作るの前提の作りで複雑化していった経緯があって。

GUIベースのエディタと相性悪い部分多かったんですよね。
例えば、親子関係のあるアイテムが、設定ファイルの順番依存（設定ファイルで親が子より前の行になければならない）とか。

そのへんでかなりコードが複雑化していって、これメンテとか無理だろってなったんですよね。
若気の至りｗ

で、そんなん思い出してたところで、テキストベースで編集補助（入力補完的なの）とプレビュー表示付ける程度なら結構簡単につくれるんじゃね？
となって。

ああ、そういう方向で作ればもっとシンプルに作れそうだったじゃん。
と、今になっての気付きがあったりして、意外と簡単に作れそうじゃんとなったので作ってみようかなという気になったのです。

その次の
・マンガミーヤの代替ツール(64bit、Unicode対応、7zip使用)
・書庫内編集ツールアップデート(64bit化&7zip使用)
は、基本的に前者は表示特化。後者は書庫内ファイルの編集特化なだけで、共通部分がかなりあるので、コードもかなり共用部分が多い感じなので、まとめて作る感じになりそうぽ。

書庫内編集ツールの方は昔作ったやつを現役で使ってるのですが、色々と機能追加やバグフィックス、更にはまだ32bit版……winxp時代？ いや流石にwin7になってたかな？
でもまだ32bitアプリもまだまだ多い時代で、完全に64bitに移行する前な時代のころに作ったツールだったりする。
ちょいちょいバグフィックスぐらいはしてたんですけどね。
根本的に刷新しないとなぁと思い続けて、気がついたらもう何年経ってるんだって感じ（ぉ


で、そこまで終わったところで、やっとwiz風の3DダンジョンRPGのゲーム開発を演る予定……

なんかその時用のネタ帳がどんどん肥大化してたりしてますｗ
ネタ考えてるときが一番楽しいよね……。

はぁ。
とにかく、一つ一つ終わらせていこう。