堕天使の煉獄

終わりも見えてきたし、ぺぺいと終わらせようとおもってたのに……

なんか何度も何度もドツボにはまって全然終わらねぇ。


ドツボ1

QtConcurrentでcancelとかsuspend(一時停止)とかresume(一時停止からの再開)辺りを組み込む。

で、cancelおよびfinishedからのサムネリスト再作成をすると、なぜかすぐに止まってしまう。
再作成の時だけ止まる。

細かく状態を監視してみると、started(開始された)のすぐあとにcanceled(キャンセルされた)が即座にemitされてる模様。なんで？

たまーに最初の一件だけサムネ画像が出てる時もあるんだけども。
別スレッドで実行されるリストを順次処理するループの中で、外でcancelされた時にループを中断するためのif(promise.isCanceled())の所で、1順目で必ずisCanceledがtrueになってるっぽい。

一体何処で？？

考えられるのは、まだ前回のスレッドが残ってて、finishedの後の状態が引き継がれてる？

再読込前にwatcherでcancelしてみたりwaitForFinishedしてみたり、deleteしてみたり……。

果ては、たまに関数ちょくで呼ぶのでなく、一旦シグナル発信してどっかで受け取ってそこで処理する。
以前何かで、そういう感じにしないとなにかの事前処理待ちが終わる前に関数実行してしまうので、そうすることで処理開始を遅延するとうまくいくみたいなのがあったので試してみたものの、状況は全然変わらず。

なんでだ？

と2時間ぐらいアレやコレや試したり、ぐぐって色々と調べてみたりしたんだけども全く解決せず。
ぐぐって出てきたサンプルみても、普通にシンプルに組んでも普通に動くっぽいのに、なんで動かない？？

……で、結局は、リスト上で右クリックメニューから「リストを再読み込み」を選択すると、リスト再読み込みする感じなんだけども。

そのメニューの処理がQActionにIDつけて登録して、実行後にID取得してそれをswitch文で処理を実行するって感じの作りなんですけども。

はい、このへんで気づいた人もいるかも。

breakの書き忘れでした（倒




ソース見てみたら書き忘れたのはbreakじゃなくてここでもう処理終了なのでreturnでしたけど。

「これ」書き忘れたせいで、switch文の場合は次の行も実行しちゃうんですよね。
で、その次の行で実行されるのは m_watcher.cancel()

started(開始された)のすぐあとにcanceled(キャンセルされた)が即座にemitされてるうん、プログラム通りだねぇ、あはははははははいひひひひひひひひひひひひひいｈじゃｄふぁんｄｆん：ぱｐ

どっと疲れが押し寄せる。

はぁ……breakの書き忘れ起因のバグって割とあるんですよね……。
今回のは書き忘れたというよりも、このリスト再読み込みの関数名をちょこちょこ書き換えた記憶あるので、shift+end→delッターン！　でreturnまで消しちゃった感じかなぁ……たぶん。

inspect(次世代switch文)早くこないかな。inspectだと明示的に何か書かないと次の行も実行にならない感じだったと。
…と思ったけど、ググっても出てこないな。
inspect自体まだ仕様が固まってない提案段階なので、そういうのがあった時期もあったとかなのか、単なる勘違いか。
ともかくinspectには暗黙のfallthroughは無いので、こういううっかりミスはないぽ。


てかコレググってたら、gcc7辺りからswitch caseで暗黙のfallthroughは警告出るようになったりとか。
属性で明示的にfallthroughだよって書かないと～な感じらしい。
Qt Creatorではどうなのかといえば、特に警告は出てなかったですね。
Qtはコンパイラも色々と環境に組み合わせて使うマルチプラットフォームなので、一応Q_FALLTHROUGHてのがあるみたいですけど、暗黙のfallthroughにはQt creatorでは対応しない方針なのかな。
vc++だと警告あるっぽい？
コンパイラオプション次第なのかな。

試しに-Wallとか追加してみたら、500件ほど警告がｗ
普通にQtのクラスにも大量にでてるので、こりゃQtではWall使えないですね。
んで、switch caseでのfallthrough警告はちゃんと出てましたね。
vc++でもちゃんとあるみたい。


ドツボ2

サムネカタログ表示で、サムネのサイズを設定で変更したとき、なぜかサイズが反映されない。
正確には、サムネ画像の取得は変更後のサイズで取得できてる。
でもビュー内のアイテムの表示サイズ＆表示位置が変更されない。

そいえば先日の日記で、サムネ読み込みがペロペロと少しずつ出るんじゃなくて、なんか一気に数十枚どどっと表示されて、なんかコレジャナイ感あるなーとかいってたのですが、あれはあっさり解決しました。
update()ではなく、viewport()->update()にしなきゃ行けなかったんですね。
QGraphicsViewなんかでも、なんか変更がupdate()しても更新されないぞ？　ってなった時にviewport()->update()じゃないとちゃんと再描画してくれないての、過去に何度もあったじゃんってなったり。
ちょっと間空くと忘れちゃうんだよな……。
ということで、ぺろぺろと一枚ずつ読み込まれて表示される感じに。コレコレ。

で、今回もそんな感じのあれかな？　
viewport()->update()辺りは真っ先に。
updateGeometry？　changeSizeHint？といろいろと試したけども、なんでかサイズ変更が反映してくれない。

なじぇぇぇぇ！？

解決方：

listView->setGridSize(変更後のサイズ);

……そこかよ……ItemDelegateとかその辺のばっかり調べてたよ。

コンストラクタ辺りで設定したっきり一度も触らなかったので完全に意識の外でした。
げふうっ。

デカいハマりはこの2つ。

あとは細かいハマりがいくつもいくつも……。
他には、サムネ取得にもsusieプラグイン使えるように処理追加したりとか。

そんなこんなで、あとはキーボードのショートカット周りの設定画面を作ればとりあえず完成ってところまで漕ぎ着けたり。

あともうちょっと……。
でもこのショートカット周りの設定画面て結構面倒そうなんだよな。

QKeySequence使った設定周りとか、現状はとりあえず実装してみた感じで、メインウィンドウのコンストラクタ辺りにべべいと書いてたりするので、この辺別クラスにまとめたりとかもちょっと切り分けしないとなとか。

あと現状、機能に対して一つのkeyしか設定できないけど、次＆前のファイルへ辺りは複数欲しかったりするかなぁとか。

あとマウス周りの設定uiも作らないとな。

基本的にいろんな動作はコマンドとして抽象化してるので、それらを選択して割り当てるだけなんだけども、細々とコードを書かなきゃ行けないので、作業量は結構多かったりして億劫だなぁ。

そういえば、先日の記事で書いたけど、このツールを画像ビューワとして画像ファイルに関連付けするとして。
ファイルのアイコンどうするかなと。
できればjpg、png、bmp、gifとか拡張子でアイコンとか変えられる方が見た目で判別できて便利なんだけどなぁ……けどどうやるん？
uLilithとかGOMプレイヤーとか、拡張子別でアイコン色違いにとか出来てましたよね。ああいうの。

……ちょっと調べてみたところ、拡張子ごとにアイコンを変更するのはWindows 7以降できなくなったという記事が出てくる。

おそらく、レジストリ直接書き換える方法とかならいまでも出来そうだけども。
なんか結構あのへんカオスで、変更が反映したりしなかったり、表示がバグったりとか変な感じになること結構多いんですよね。

そういうのもあってか、win10以降？　は、設定から規定のプログラムを選択で設定する方式のほうがメインで。
そっちだとアプリに設定されてる単体のアイコンしか使えないっぽい。

んでも、古いツールとの互換性のために、昔のやり方も使えるので、おそらくいまでもGOMとかで拡張子別のアイコンとか出来るんじゃないかな。
でもレガシーなやり方というだけでなく、昔ちょっと触ったことあるけどあの辺めっちゃめんどくさい＆複雑な感じで、もう二度と触りたくない感じだったんですよね。

なので、拡張子ごとにアイコンを変更するのは諦めるっ。


その代わり、Tablacus Explorerっていうファイラー使ってるのですが、このファイラー独自に拡張子ごとにアイコンを変更する機能あるんですよね。
レジストリとかwindowsのシステムいじらないで、このファイラー上でだけアイコン変えるっていう機能が。

未だに進捗報告版であるsai2はアイコンもないので、有志がつくたアイコンを設定して使ってたりしてます。
起動するアプリの関連付けも同様にこのファイラー上でだけ動作する設定があるので、*.sai2でsai2を起動出来るようにしてるぽ。
設定の書き換えも簡単なので、新しい進捗報告版出た時にパス書き換えるだけで良いので便利ぽ。
windowsの設定をいじらないで変えてくれるというのが素晴らしい。

なので、画像のフォーマット別にアイコン変えるのとかもコレで変えちゃうかなと。
完全におま環仕様ですけどｗ



んで、コレが終わったら書庫ファイル内の画像をなにやらするツール……Qt5.11ビルドな上に32bitアプリなんだこの旧作アプリ。
てか64bitアプリをデフォにしだして随分経ったと思うけど、まだ32bit版で作ってた頃だと相当前の気がするなぁ。
その頃からずっと作り直したいと思ってるツールなので、早いとこ刷新したい所。


でもその前にもう一個作りたいツール出てきたんですよね。
FileSeeker3の代替ツール。

ファイル検索ソフトは数あれど、検索場所のフォルダを複数登録してそこから検索って感じのはこのソフトだけなんですよね。
とにかく全部から検索ってのなら「Everything」だけど。

自分で作るなら、タブで用途別に分けるとかも欲しいかな。
「画像」「音楽」「動画」とかタブでわけて、それぞれに検索したいフォルダをいくつも登録して、検索する感じで。

FileSeeker3は結構動作が不安定でちょくちょくぶち落ちる事あるのと、検索ワードの履歴機能が無いのが致命的な欠陥なんですよね。

でも検索したいフォルダを複数登録してそこから検索ってのが他にはないので、結局未だに使い続けてる感じで。

んで、自作するにも、問題になるのは検索スピード。
MFTと独自のインデックスDB作成両方やってるらしいんですけども。

なにげにQtのファイルリスト周りMFT参照してるみたいな記事をどこぞでみかけて。
真偽は定かではないのですが。
でもQtのファイル列挙とか結構速いよねと。
なんかキャッシュも内部でなんかやってるっぽい？？
なので、実際に作ってみて速度試してみる価値はあるかなぁと。

あんまり複雑な検索条件は考えないで単純に検索文字列が含まれてるファイルを列挙するだけのシンプルな感じで。
実際FileSeeker3も自分はその用途でしか使ってないし。

そうなると割と作りもシンプルなので、すぐに作れるかなぁと。

FileSeeker3の使い勝手のいいところはもう一つ。
検索結果のファイル＆フォルダのリネームと削除、D&Dでの移動＆コピー、エクスプローラと同じ右クリックメニューに関連付けされたアプリでの起動と、検索結果のファイルに対して、普通のファイラーの機能が使える点。

これがQtやろうと思うと結構めんどい。特に右クリックメニューが。
なんかコンテキストメニュー自体をwin32APIから作成したウィンドウを作る必要があるとかで。
でもまあ、ソースコード付きで解説してるとこブックマークしてあるのでなんとかなるでしょ（ぉ

これは作ってみないと実用に足るのか判らないなぁ。



あとは、なんか最近親知らずが痛くなってきた……。

以前からちょいちょい痛むことはあったんですが、今回はなんか喉まで痛くなってきて。
ぐぐってみると、下の歯の親知らずだと、喉まで痛くなることあるみたいで、まさにコレっぽいぞと。
今回は本格的に痛みだしてきた感じなので、こりゃ抜くしか無いかなぁ……と。

昔、親知らずは20代までに全部抜いとくほうがいいみたいなの見たなぁ。
歳食ってからだと治りも遅いし、痛みもひどいとかで。
まあ後の祭りかｗ

はーめんどくさ。