堕天使の煉獄
2025-03
19
02:48:33
なんか妙に時間かかったな
とりあえず、susieの代替の自作画像ビューワほぼ完成ぽ。
なんかえらく時間かかったなぁ。
まあ、実作業時間が少ないものな。
最近ほんと集中力が続かなくなってきたなぁ。
あとは、一番面倒くさいというか、作業感強くてさらに物量も多いという、設定画面周りの作業ってことで、まったくやる気が湧いてこなかったというのもあるぽ。
キーボードコンフィグ周り

参考にしたところだと、項目がグループ分けされてたりしたんですが(「ファイル」「編集」とかそういうの)今回のは全体でも10数件しかコマンド無いので、グループとか要らないよなと言うことでシンプルに。
ショートカットキーのキャプチャ周りは、参考にしたところだと、チェック付きのボタン使って、そのボタンクラスのチェックのトグル動作でキャプチャのon・off切り替えてて、なるほどなーとなったんだけども。
そこに気づいたのはざっと眺めて自分なりにQLineEditで実装してからでした。
自分のではfocusInとOutでキャプチャの切り替えをしてたり。
キャプチャ開始すると、EventFilterですべてのイベントをキャッチして入力が終了するまで何も動作させない感じにするんだけども、右クリックでキャンセル出来る感じにしてみたり。
んーボタンのトグル動作でオンオフのがうまく出来てる感あるなぁ……でもまあ問題なく動いてるしこれでいいか(ぉ
マウス設定周り

ポップアップとかポップアップのフォントとか設定がちまちま増えちゃったり。
バッサリ設定省くのも考えたんだけども、今やらないと一生追加しないだろうなってことで気力を振り絞って追加(ぉ
スワイプ時の線の色とかも設定……いいかメンドイ……。
そんな感じで、とりあえず大体出来た~。
もうちょいちょこちょこ弄りたいところも少しあったりもするんですけどね。
あとはアプリのアイコンとかもどうしようかな。
アプリの性質上、関連付けすると画像ファイルのアイコンがこのアプリのアイコンになるので、なんかそれっぽいの用意したい所。
その辺ちょっとググったら、Faviconジェネレーターっていう便利サイトがあるんやね。
こりゃ便利そう。
普段iconなんて作らないからなぁ。
馴染なさ過ぎて何で作ったらいいのやら。
ドットエディタとかで作るのかな? とかおもってたので。
話は変わって。
ここのレンタル鯖の請求がきてたんだけども。
7150円……ふおっめっちゃ値上がりしてるぅ。
ぐぐってみたら
5238円 → 6600円
で、税込みで7150円ナリ。
だそうな。
値上がり額は1300円ぐらいなんだけども、額面が前は税込みでも5000円代だったので、7000円台になるとめっちゃ値上がり感するなぁ。
気分的には2000円上がった感w
これが6950円ぐらいで止まってたら、千円ぐらいあがったのかぁって感じなんですけどね。
しかしまあ、値上がりはご時世的にしゃーないか。
またまた話変わって。
つべに久々に伊集院さんの生配信(テスト)が上がってたので見てたんだけども。
そこで知ったんだけども、最近では深夜の馬鹿力の笑い屋もやってるらしい、河野かずおのチャンネルで伊集院さんも一緒にやってるプレイ動画(ライブ)がいくつも上がってたりで。
The Planet Crafterっていう宇宙で生産開拓ゲー。
一本4時間ぐらいあるのが何本もあって、流しながらだとちっともPGすすまねぇ(ぉ
その辺も進行が遅々としていた原因だったりw
最近はずーっと収集はしてるものの、深夜の馬鹿力ぜんぜん聴けてないんだよな。
未だ2019年のところで止まってる。
構成の渡辺くんが卒業する話が出始めた辺り。
わりと渡辺ロス(まだ卒業前までしか聴いてないけど)の所為で、続きを聴く意欲が減退してる部分もあったりで。
んで、その配信のなかの雑談で、公園の危険な遊具の話になって。
そこで構成の渡辺くんが子供の頃、近所の公園の遊具を撤去させまくってた話(運動神経がキレてるので遊具で怪我→撤去の流れ)がでてきて、いまでも渡辺くんの話とかでてくるんだ~となって、ちょっとうれしくなったり。
うーん馬鹿力の続き聴こうかな。
配信の中の会話から、馬鹿力でこのゲームにハマってる~からの配信のの流れらしいので。
「タモリ」と呼ばれるゴーグル型のモニタ? の話とか、最初は何? とおもったんだけども。
そのへんは馬鹿力もリアルタイムで聴いてないと通じない感じでちょっと淋しい感じ。
もともとリアルタイムで聞ける地域に住んでないので、生で聴いたことないんですけどね。
現在放送回は1500回を超えてるんだけども、300~500回ぐらいあたりのは、最新のまで聴いちゃったらまた第一回から聞き始める……なんてのを数回繰り返してたんだけどなぁ。
いまでは最新回ははるか先になってしまったなぁ。
現在第1249回でとまってるぽ。
というのも、昔はお絵かきで色塗りするときに馬鹿力を聴くっていう感じで。
それだけ昔は毎日絵をかいてたんだなぁと(ぉ
で、ここ最近は渡辺ロスもあってか、同人作業の色塗りの時も普通に音楽聴いてたりしちゃってたので。
でも今回の配信みて、また聴くの再開しようかなという気になってきてたり。
なんかえらく時間かかったなぁ。
まあ、実作業時間が少ないものな。
最近ほんと集中力が続かなくなってきたなぁ。
あとは、一番面倒くさいというか、作業感強くてさらに物量も多いという、設定画面周りの作業ってことで、まったくやる気が湧いてこなかったというのもあるぽ。
キーボードコンフィグ周り

参考にしたところだと、項目がグループ分けされてたりしたんですが(「ファイル」「編集」とかそういうの)今回のは全体でも10数件しかコマンド無いので、グループとか要らないよなと言うことでシンプルに。
ショートカットキーのキャプチャ周りは、参考にしたところだと、チェック付きのボタン使って、そのボタンクラスのチェックのトグル動作でキャプチャのon・off切り替えてて、なるほどなーとなったんだけども。
そこに気づいたのはざっと眺めて自分なりにQLineEditで実装してからでした。
自分のではfocusInとOutでキャプチャの切り替えをしてたり。
キャプチャ開始すると、EventFilterですべてのイベントをキャッチして入力が終了するまで何も動作させない感じにするんだけども、右クリックでキャンセル出来る感じにしてみたり。
んーボタンのトグル動作でオンオフのがうまく出来てる感あるなぁ……でもまあ問題なく動いてるしこれでいいか(ぉ
マウス設定周り

ポップアップとかポップアップのフォントとか設定がちまちま増えちゃったり。
バッサリ設定省くのも考えたんだけども、今やらないと一生追加しないだろうなってことで気力を振り絞って追加(ぉ
スワイプ時の線の色とかも設定……いいかメンドイ……。
そんな感じで、とりあえず大体出来た~。
もうちょいちょこちょこ弄りたいところも少しあったりもするんですけどね。
あとはアプリのアイコンとかもどうしようかな。
アプリの性質上、関連付けすると画像ファイルのアイコンがこのアプリのアイコンになるので、なんかそれっぽいの用意したい所。
その辺ちょっとググったら、Faviconジェネレーターっていう便利サイトがあるんやね。
こりゃ便利そう。
普段iconなんて作らないからなぁ。
馴染なさ過ぎて何で作ったらいいのやら。
ドットエディタとかで作るのかな? とかおもってたので。
話は変わって。
ここのレンタル鯖の請求がきてたんだけども。
7150円……ふおっめっちゃ値上がりしてるぅ。
ぐぐってみたら
5238円 → 6600円
で、税込みで7150円ナリ。
だそうな。
値上がり額は1300円ぐらいなんだけども、額面が前は税込みでも5000円代だったので、7000円台になるとめっちゃ値上がり感するなぁ。
気分的には2000円上がった感w
これが6950円ぐらいで止まってたら、千円ぐらいあがったのかぁって感じなんですけどね。
しかしまあ、値上がりはご時世的にしゃーないか。
またまた話変わって。
つべに久々に伊集院さんの生配信(テスト)が上がってたので見てたんだけども。
そこで知ったんだけども、最近では深夜の馬鹿力の笑い屋もやってるらしい、河野かずおのチャンネルで伊集院さんも一緒にやってるプレイ動画(ライブ)がいくつも上がってたりで。
The Planet Crafterっていう宇宙で生産開拓ゲー。
一本4時間ぐらいあるのが何本もあって、流しながらだとちっともPGすすまねぇ(ぉ
その辺も進行が遅々としていた原因だったりw
最近はずーっと収集はしてるものの、深夜の馬鹿力ぜんぜん聴けてないんだよな。
未だ2019年のところで止まってる。
構成の渡辺くんが卒業する話が出始めた辺り。
わりと渡辺ロス(まだ卒業前までしか聴いてないけど)の所為で、続きを聴く意欲が減退してる部分もあったりで。
んで、その配信のなかの雑談で、公園の危険な遊具の話になって。
そこで構成の渡辺くんが子供の頃、近所の公園の遊具を撤去させまくってた話(運動神経がキレてるので遊具で怪我→撤去の流れ)がでてきて、いまでも渡辺くんの話とかでてくるんだ~となって、ちょっとうれしくなったり。
うーん馬鹿力の続き聴こうかな。
配信の中の会話から、馬鹿力でこのゲームにハマってる~からの配信のの流れらしいので。
「タモリ」と呼ばれるゴーグル型のモニタ? の話とか、最初は何? とおもったんだけども。
そのへんは馬鹿力もリアルタイムで聴いてないと通じない感じでちょっと淋しい感じ。
もともとリアルタイムで聞ける地域に住んでないので、生で聴いたことないんですけどね。
現在放送回は1500回を超えてるんだけども、300~500回ぐらいあたりのは、最新のまで聴いちゃったらまた第一回から聞き始める……なんてのを数回繰り返してたんだけどなぁ。
いまでは最新回ははるか先になってしまったなぁ。
現在第1249回でとまってるぽ。
というのも、昔はお絵かきで色塗りするときに馬鹿力を聴くっていう感じで。
それだけ昔は毎日絵をかいてたんだなぁと(ぉ
で、ここ最近は渡辺ロスもあってか、同人作業の色塗りの時も普通に音楽聴いてたりしちゃってたので。
でも今回の配信みて、また聴くの再開しようかなという気になってきてたり。
2025-03
14
05:44:32
ドツボにはまりすぎてへん
終わりも見えてきたし、ぺぺいと終わらせようとおもってたのに……
なんか何度も何度もドツボにはまって全然終わらねぇ。
ドツボ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されてるうん、プログラム通りだねぇ、あはははははははいひひひひひひひひひひひひひいhじゃdふぁんdfん:ぱp
どっと疲れが押し寄せる。
はぁ……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件ほど警告がw
普通に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の設定をいじらないで変えてくれるというのが素晴らしい。
なので、画像のフォーマット別にアイコン変えるのとかもコレで変えちゃうかなと。
完全におま環仕様ですけどw
んで、コレが終わったら書庫ファイル内の画像をなにやらするツール……Qt5.11ビルドな上に32bitアプリなんだこの旧作アプリ。
てか64bitアプリをデフォにしだして随分経ったと思うけど、まだ32bit版で作ってた頃だと相当前の気がするなぁ。
その頃からずっと作り直したいと思ってるツールなので、早いとこ刷新したい所。
でもその前にもう一個作りたいツール出てきたんですよね。
FileSeeker3の代替ツール。
ファイル検索ソフトは数あれど、検索場所のフォルダを複数登録してそこから検索って感じのはこのソフトだけなんですよね。
とにかく全部から検索ってのなら「Everything」だけど。
自分で作るなら、タブで用途別に分けるとかも欲しいかな。
「画像」「音楽」「動画」とかタブでわけて、それぞれに検索したいフォルダをいくつも登録して、検索する感じで。
FileSeeker3は結構動作が不安定でちょくちょくぶち落ちる事あるのと、検索ワードの履歴機能が無いのが致命的な欠陥なんですよね。
でも検索したいフォルダを複数登録してそこから検索ってのが他にはないので、結局未だに使い続けてる感じで。
んで、自作するにも、問題になるのは検索スピード。
MFTと独自のインデックスDB作成両方やってるらしいんですけども。
なにげにQtのファイルリスト周りMFT参照してるみたいな記事をどこぞでみかけて。
真偽は定かではないのですが。
でもQtのファイル列挙とか結構速いよねと。
なんかキャッシュも内部でなんかやってるっぽい??
なので、実際に作ってみて速度試してみる価値はあるかなぁと。
あんまり複雑な検索条件は考えないで単純に検索文字列が含まれてるファイルを列挙するだけのシンプルな感じで。
実際FileSeeker3も自分はその用途でしか使ってないし。
そうなると割と作りもシンプルなので、すぐに作れるかなぁと。
FileSeeker3の使い勝手のいいところはもう一つ。
検索結果のファイル&フォルダのリネームと削除、D&Dでの移動&コピー、エクスプローラと同じ右クリックメニューに関連付けされたアプリでの起動と、検索結果のファイルに対して、普通のファイラーの機能が使える点。
これがQtやろうと思うと結構めんどい。特に右クリックメニューが。
なんかコンテキストメニュー自体をwin32APIから作成したウィンドウを作る必要があるとかで。
でもまあ、ソースコード付きで解説してるとこブックマークしてあるのでなんとかなるでしょ(ぉ
これは作ってみないと実用に足るのか判らないなぁ。
あとは、なんか最近親知らずが痛くなってきた……。
以前からちょいちょい痛むことはあったんですが、今回はなんか喉まで痛くなってきて。
ぐぐってみると、下の歯の親知らずだと、喉まで痛くなることあるみたいで、まさにコレっぽいぞと。
今回は本格的に痛みだしてきた感じなので、こりゃ抜くしか無いかなぁ……と。
昔、親知らずは20代までに全部抜いとくほうがいいみたいなの見たなぁ。
歳食ってからだと治りも遅いし、痛みもひどいとかで。
まあ後の祭りかw
はーめんどくさ。
なんか何度も何度もドツボにはまって全然終わらねぇ。
ドツボ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されてるうん、プログラム通りだねぇ、あはははははははいひひひひひひひひひひひひひいhじゃdふぁんdfん:ぱp
どっと疲れが押し寄せる。
はぁ……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件ほど警告がw
普通に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の設定をいじらないで変えてくれるというのが素晴らしい。
なので、画像のフォーマット別にアイコン変えるのとかもコレで変えちゃうかなと。
完全におま環仕様ですけどw
んで、コレが終わったら書庫ファイル内の画像をなにやらするツール……Qt5.11ビルドな上に32bitアプリなんだこの旧作アプリ。
てか64bitアプリをデフォにしだして随分経ったと思うけど、まだ32bit版で作ってた頃だと相当前の気がするなぁ。
その頃からずっと作り直したいと思ってるツールなので、早いとこ刷新したい所。
でもその前にもう一個作りたいツール出てきたんですよね。
FileSeeker3の代替ツール。
ファイル検索ソフトは数あれど、検索場所のフォルダを複数登録してそこから検索って感じのはこのソフトだけなんですよね。
とにかく全部から検索ってのなら「Everything」だけど。
自分で作るなら、タブで用途別に分けるとかも欲しいかな。
「画像」「音楽」「動画」とかタブでわけて、それぞれに検索したいフォルダをいくつも登録して、検索する感じで。
FileSeeker3は結構動作が不安定でちょくちょくぶち落ちる事あるのと、検索ワードの履歴機能が無いのが致命的な欠陥なんですよね。
でも検索したいフォルダを複数登録してそこから検索ってのが他にはないので、結局未だに使い続けてる感じで。
んで、自作するにも、問題になるのは検索スピード。
MFTと独自のインデックスDB作成両方やってるらしいんですけども。
なにげにQtのファイルリスト周りMFT参照してるみたいな記事をどこぞでみかけて。
真偽は定かではないのですが。
でもQtのファイル列挙とか結構速いよねと。
なんかキャッシュも内部でなんかやってるっぽい??
なので、実際に作ってみて速度試してみる価値はあるかなぁと。
あんまり複雑な検索条件は考えないで単純に検索文字列が含まれてるファイルを列挙するだけのシンプルな感じで。
実際FileSeeker3も自分はその用途でしか使ってないし。
そうなると割と作りもシンプルなので、すぐに作れるかなぁと。
FileSeeker3の使い勝手のいいところはもう一つ。
検索結果のファイル&フォルダのリネームと削除、D&Dでの移動&コピー、エクスプローラと同じ右クリックメニューに関連付けされたアプリでの起動と、検索結果のファイルに対して、普通のファイラーの機能が使える点。
これがQtやろうと思うと結構めんどい。特に右クリックメニューが。
なんかコンテキストメニュー自体をwin32APIから作成したウィンドウを作る必要があるとかで。
でもまあ、ソースコード付きで解説してるとこブックマークしてあるのでなんとかなるでしょ(ぉ
これは作ってみないと実用に足るのか判らないなぁ。
あとは、なんか最近親知らずが痛くなってきた……。
以前からちょいちょい痛むことはあったんですが、今回はなんか喉まで痛くなってきて。
ぐぐってみると、下の歯の親知らずだと、喉まで痛くなることあるみたいで、まさにコレっぽいぞと。
今回は本格的に痛みだしてきた感じなので、こりゃ抜くしか無いかなぁ……と。
昔、親知らずは20代までに全部抜いとくほうがいいみたいなの見たなぁ。
歳食ってからだと治りも遅いし、痛みもひどいとかで。
まあ後の祭りかw
はーめんどくさ。
2025-03
08
00:47:04
アウアウア
気がついたら3月入って一週間たってたり。
しばらく根詰めてPGやってたので、ちょっと息抜きで色々と他事やってたり、積んでた本とか読んでたらなんか時間があっという間に過ぎてたり……。
一度歩みを止めるとトルクがなさ過ぎて再始動がとても鈍いんですよね最近。
とりあえずさっさと終わらせて次に行きたい所なので、頑張って作業再開。

サムネイルのカタログ表示、別スレッドで読み込みな感じの。
なんかテストに手頃で、かつ出しても良い画像がそれなりの枚数ある所てので、昔のお絵かき用ワークのフォルダを使ってテスト。
なにげにまだこの頃、アナログでコピー紙にシャーペンで描いてた時代ぽ。
なので画像フォーマットがBMPでクソでかい(30MBとか)ファイルもいっぱいあったのだけども。
なんでBMPかといえば単純にスキャナでスキャンした画像だからです。
そこから写真屋でレベル補正とかかけて線画をくっきり出した……後の画像ですね右側の画像は。
この頃は、そこからsaiで線画をペン入れしてた頃かな。
ほとんどなぞるだけの単純作業で、作業感あってあんまり創造性のない作業な気がしてあんまり好きじゃなかった作業だったなぁ。
ここ最近は線画から全部フルデジタルに移行しちゃったので、アナログで絵なんてもう何年描いてないだろうか……。
閑話休題。
別スレッドでのサムネ画像作成、実行してみたら一枚ずつぺぺぺ……と画像が表示されるの想像してたんだけども、一瞬で20枚ぐらいがぺっと表示されたあと、一瞬間をおいて残りが表示されたり。
試しに設定したのが80*100サイズのサムネなんですけど(上の画像はブログ貼り付けようにちょびっと縮小してるので実サイズではないです)30MB位あるBMPなんかも複数枚あるのにわりと一瞬で表示されてなんかエラく速いなと。
一応一枚ごとに表示をupdate()してるしてるのですが、間隔が短すぎて一気に表示されてる感じっぽい。
それとも別スレッドからのシグナルの受け渡し間隔の問題??
んでメモリ使用量もサムネ画像のサイズが小さすぎたのか、ほとんどわからないぐらいの微増しかしてないっぽい。
なんか思ったよりも読み込み速すぎて、逆になんかコレジャナイ感がw
んで、今回はQt6から入った新機能のPromiseモード(QPromise)を使ってみる初テストだったりもする。
途中で中断したり再開したりが簡単に出来るので、大量のリストがあった場合には、一括で最後までサムネ作成しないで一旦止めて。
スクロールバーでスクロールした時に再開する感じとか出来そうだなと思ったのですが。
表示部分はQListViewで、flowモードってのにしてるのだけども。
HTMLとかのレイアウトでやるようなやつですね。
画面の端に来たら自動で折り返す感じのやつ。
それと順次ロード待ちの組み合わせ、なんか相性悪いというか、めちゃ複雑な感じになりそうで、ちょっとどうしようか悩み中。
ウェブページみたく、ページ切り替えできっちり区切りついた感じだったらまだやりやすいんですけどね。
イメージ的にはアドオンとかである、何ページもある内容で、スクロールバーを下に持ってくと次のページを現在のページの下部に続けて読み込んで表示するヤツ。
あんな感じだとページ単位で読み込み済みと未読込の管理もしやすいんですけどね。
大量にある時に、スクロールでずっと下部に移動したら移動後の場所のページを読み込み始めるけど、その間の部分は未読込のままとか出来るし。
それがflowレイアウトで、かつサムネイルの画像サイズも設定で可変とかなると、ウィンドウのリサイズでページ単位が変更されたりしてしまうので、困った感じになってしまうんだけども。
でもページ切り替えってのもなんかそれはそれで微妙な気もするしなぁと。
んー。
とりあえず、一度に読み込む最大件数だけ設定して。
もっと読み込むかは最大件数に達する毎に選択(コンテキストメニューからとかで)させる感じでいいかなぁ……それが一番面倒なさそう。
別スレッドなのでバックグラウンドで読み込み続けるにしても、流石に数万件とか読み込ませ初めたら止まらないってのはマズイものね。
しかし、シグナル・スロットで別スレッドで動いてるのを簡単に制御出来るこの仕組みは素晴らしいですね。
昔はもっと低レベルなQThread使って、ほんとにこのやり方でええんかいって感じなのでやってたので。
それに比べたらQtConcurrentの高レベルなスレッド周りはとてもシンプルに組めて楽でよいです。
プチ中断する前というか、中断する契機になったのが、この別スレッドでまわす関数の中身で、範囲ベースのfor文書く所で、そういえばなんかc++23とかでrangeてのあったよね。あれもうvc++でも使えるんだっけか?
って言うところから、最近のvc++のc++2xの対応状況調べ始めたところでかなり長い時間調べ物してた所為で気持ちが途切れちゃったってのがあったり。
でもまあ、色々と収穫もあったので無駄ではなかったんですけどね。
cpprefjp - C++日本語リファレンス
ttps://cpprefjp.github.io/
ここは個人(数人の有志?)がやっているようで、コンパイラの実装状況とか最新の情報が常にあるってわけでもないのですが、幅広く網羅しているので新しく入った新機能とか調べるときには大体ここ見れば済むって感じでお世話になっております。
が、vc++の対応状況は全然実態と違うんですよね。
といってもここの人が悪いわけでもなく。
基本的に、c++latestはまだ正式対応という感じじゃないっていう扱いみたいで、一応使えるのに対応表では未対応表記……ってのがとてもめんどくさい。
そして、rangesはc++20以降いくつも機能が追加されてるんだけども、vc++の方も順次対応を進めてる感じでvc++のバージョンの何処から何が使えるようになるのか。
最新版だと何処まで使えるのか。っていうのがとても把握しづらくて……。
対応表を見ただけだと使えないと諦めてたものが、実はc++latestだとあっさり使えるとか結構多くて、なんだよもう……って感じになるのが多すぎる……。
んで結局vc++の少し前のバージョンから更新リストをずーっと見直して、あ、これもう使えるんじゃねーかとかそんなんで数日費やしてたり。
んで結果として、rangesは一応現時点では実装が完了してるらしい。
ただ、まだまだ内部の最適化は継続中……みたいな感じらしいんですけど。
でもとりあえず動くらしい。
以前調べた時は中途半端に対応途中だったので、使えるものと使えないもの調べるの面倒になって、全部終わってから使おうって感じで見送ったので。
ようやく使えるようになったんだーってのを今回知れたのは収穫だったかな。
んでQt上で実際に使ってみた所、特に警告とかも波線とかも出たりせず、すんなり使えたり。
解析がclang使ってるからですかね。
まだc++11~17辺りだと、vc++だともう使えるけどQt Creatorの方では対応してなくて警告出たり、酷いのだとその部分以降ハイライタがぶっ壊れたりとか面倒な感じになったこともあったなぁ。
その辺clangに投げる方向に進んだのは慧眼だったんだなぁと。
てかコンパイラの対応表みてると、clangは先進的で突っ走ってるけどここ何年かはgccがきっちり追従してるのが変わったなぁとか。
c++11~17ぐらいまでは結構gccは対応遅かった印象なので。
それどころかc++26だとgccのが先に対応してるのとかあるし。
逆に最近はvc++がかなり微妙だったりで。
c++23の言語機能の方、ここ数年まったく進んでなかったりするし。
if constevalいつになったら使えるねん……。
でもc++23の標準ライブラリ機能の方はほぼ実装済みみたいで、そっちに全部のリソースつぎこんでる感じなんですかね。
c++26の方はまだぜんぜん白紙っぽいですけど。
ていうかinspectはまだ来ないのかなぁ。
次世代のswitch case文とも言うべきinspect。
CEDEC 2024『ゲーム開発者のための C++17~C++23, 近年の C++ 規格策定の動向』
ttps://www.docswell.com/s/cpp/5XEY92-cedec2024#p1
今回色々調べてた時に出てきたスライドなんだけども、新旧包括的に網羅されてるので、復習と新規の両方学べてとてもいいスライドでした。
……ただ、新規の方はvc++で対応してるのか調べながら見てたので全部見終わるのにえらく時間かかった……。
optionalのモナドとかもう使えるのかぁ……いつの間に。
めっちゃ種類あるのなrangeアダプタ。
便利だけども、空で使い分けられるかと言うと……どっかに一覧まとめて置いとくとかしないと適宜に使いこなせなさそうw
んで、ここの最後の方でちょっとinspectにも触れられてたんだけども。
なんかC#とかっぽく「as」キーワード入れたりとか「let」とか、書き方のところで意見が割れてたりとかでごちゃごちゃやってるらしい……。
んでc++29になりそうとか……うぐぅ。
とりあえずまあ現状c++で欲しいのは「inspect」と「c++26では削除されるcodecvtの代替」の2つが筆頭ですかね。
後者はほんとどうにかして欲しい。
だから未だにc++は文字周りダメダメだよねと言われるんだよ(ぉ
Qtでもunicodeの相互変換はできるけど、shift-jisが切られちゃって変換するのに困る感じになっちゃってるんですよね。
未だにzipフォーマットの中身の文字はshift-jis多いんだよ……。
まあwin環境に限ればWinApiで文字コード変換辺りはなんとかなってるけども。
でもできれば環境依存コードなWinApi使わないで済ませたいですよね。
そんな感じで、susie代替のビューワ、あとは細かい設定周りと設定画面のui辺り作ったらとりあえず完成かな。
んでも画像ファイルへの関連付けの仕方がwin10以降? から変わったけど、関連付けたファイルのアイコンの設定とかどうやるんだろね。
その辺まだ全然調べてもないや。
いまウチのpcだと、とりあえず代替で使ってた画像ビューワに設定して以降、bmpもjpgもpngもみーんな同じアイコンになっちゃってるんだよな。非対応のavifだけ違うアイコンになってるけど。
拡張子で細かく分けるのとかは、新しい関連付け方式の方だとどうやって設定するんだろね。
できればタイプ別で同じアイコンでも色違いとかにしたいなぁ。
そのへんも調べとかないとな。
しばらく根詰めてPGやってたので、ちょっと息抜きで色々と他事やってたり、積んでた本とか読んでたらなんか時間があっという間に過ぎてたり……。
一度歩みを止めるとトルクがなさ過ぎて再始動がとても鈍いんですよね最近。
とりあえずさっさと終わらせて次に行きたい所なので、頑張って作業再開。

サムネイルのカタログ表示、別スレッドで読み込みな感じの。
なんかテストに手頃で、かつ出しても良い画像がそれなりの枚数ある所てので、昔のお絵かき用ワークのフォルダを使ってテスト。
なにげにまだこの頃、アナログでコピー紙にシャーペンで描いてた時代ぽ。
なので画像フォーマットがBMPでクソでかい(30MBとか)ファイルもいっぱいあったのだけども。
なんでBMPかといえば単純にスキャナでスキャンした画像だからです。
そこから写真屋でレベル補正とかかけて線画をくっきり出した……後の画像ですね右側の画像は。
この頃は、そこからsaiで線画をペン入れしてた頃かな。
ほとんどなぞるだけの単純作業で、作業感あってあんまり創造性のない作業な気がしてあんまり好きじゃなかった作業だったなぁ。
ここ最近は線画から全部フルデジタルに移行しちゃったので、アナログで絵なんてもう何年描いてないだろうか……。
閑話休題。
別スレッドでのサムネ画像作成、実行してみたら一枚ずつぺぺぺ……と画像が表示されるの想像してたんだけども、一瞬で20枚ぐらいがぺっと表示されたあと、一瞬間をおいて残りが表示されたり。
試しに設定したのが80*100サイズのサムネなんですけど(上の画像はブログ貼り付けようにちょびっと縮小してるので実サイズではないです)30MB位あるBMPなんかも複数枚あるのにわりと一瞬で表示されてなんかエラく速いなと。
一応一枚ごとに表示をupdate()してるしてるのですが、間隔が短すぎて一気に表示されてる感じっぽい。
それとも別スレッドからのシグナルの受け渡し間隔の問題??
んでメモリ使用量もサムネ画像のサイズが小さすぎたのか、ほとんどわからないぐらいの微増しかしてないっぽい。
なんか思ったよりも読み込み速すぎて、逆になんかコレジャナイ感がw
んで、今回はQt6から入った新機能のPromiseモード(QPromise)を使ってみる初テストだったりもする。
途中で中断したり再開したりが簡単に出来るので、大量のリストがあった場合には、一括で最後までサムネ作成しないで一旦止めて。
スクロールバーでスクロールした時に再開する感じとか出来そうだなと思ったのですが。
表示部分はQListViewで、flowモードってのにしてるのだけども。
HTMLとかのレイアウトでやるようなやつですね。
画面の端に来たら自動で折り返す感じのやつ。
それと順次ロード待ちの組み合わせ、なんか相性悪いというか、めちゃ複雑な感じになりそうで、ちょっとどうしようか悩み中。
ウェブページみたく、ページ切り替えできっちり区切りついた感じだったらまだやりやすいんですけどね。
イメージ的にはアドオンとかである、何ページもある内容で、スクロールバーを下に持ってくと次のページを現在のページの下部に続けて読み込んで表示するヤツ。
あんな感じだとページ単位で読み込み済みと未読込の管理もしやすいんですけどね。
大量にある時に、スクロールでずっと下部に移動したら移動後の場所のページを読み込み始めるけど、その間の部分は未読込のままとか出来るし。
それがflowレイアウトで、かつサムネイルの画像サイズも設定で可変とかなると、ウィンドウのリサイズでページ単位が変更されたりしてしまうので、困った感じになってしまうんだけども。
でもページ切り替えってのもなんかそれはそれで微妙な気もするしなぁと。
んー。
とりあえず、一度に読み込む最大件数だけ設定して。
もっと読み込むかは最大件数に達する毎に選択(コンテキストメニューからとかで)させる感じでいいかなぁ……それが一番面倒なさそう。
別スレッドなのでバックグラウンドで読み込み続けるにしても、流石に数万件とか読み込ませ初めたら止まらないってのはマズイものね。
しかし、シグナル・スロットで別スレッドで動いてるのを簡単に制御出来るこの仕組みは素晴らしいですね。
昔はもっと低レベルなQThread使って、ほんとにこのやり方でええんかいって感じなのでやってたので。
それに比べたらQtConcurrentの高レベルなスレッド周りはとてもシンプルに組めて楽でよいです。
プチ中断する前というか、中断する契機になったのが、この別スレッドでまわす関数の中身で、範囲ベースのfor文書く所で、そういえばなんかc++23とかでrangeてのあったよね。あれもうvc++でも使えるんだっけか?
って言うところから、最近のvc++のc++2xの対応状況調べ始めたところでかなり長い時間調べ物してた所為で気持ちが途切れちゃったってのがあったり。
でもまあ、色々と収穫もあったので無駄ではなかったんですけどね。
cpprefjp - C++日本語リファレンス
ttps://cpprefjp.github.io/
ここは個人(数人の有志?)がやっているようで、コンパイラの実装状況とか最新の情報が常にあるってわけでもないのですが、幅広く網羅しているので新しく入った新機能とか調べるときには大体ここ見れば済むって感じでお世話になっております。
が、vc++の対応状況は全然実態と違うんですよね。
といってもここの人が悪いわけでもなく。
基本的に、c++latestはまだ正式対応という感じじゃないっていう扱いみたいで、一応使えるのに対応表では未対応表記……ってのがとてもめんどくさい。
そして、rangesはc++20以降いくつも機能が追加されてるんだけども、vc++の方も順次対応を進めてる感じでvc++のバージョンの何処から何が使えるようになるのか。
最新版だと何処まで使えるのか。っていうのがとても把握しづらくて……。
対応表を見ただけだと使えないと諦めてたものが、実はc++latestだとあっさり使えるとか結構多くて、なんだよもう……って感じになるのが多すぎる……。
んで結局vc++の少し前のバージョンから更新リストをずーっと見直して、あ、これもう使えるんじゃねーかとかそんなんで数日費やしてたり。
んで結果として、rangesは一応現時点では実装が完了してるらしい。
ただ、まだまだ内部の最適化は継続中……みたいな感じらしいんですけど。
でもとりあえず動くらしい。
以前調べた時は中途半端に対応途中だったので、使えるものと使えないもの調べるの面倒になって、全部終わってから使おうって感じで見送ったので。
ようやく使えるようになったんだーってのを今回知れたのは収穫だったかな。
んでQt上で実際に使ってみた所、特に警告とかも波線とかも出たりせず、すんなり使えたり。
解析がclang使ってるからですかね。
まだc++11~17辺りだと、vc++だともう使えるけどQt Creatorの方では対応してなくて警告出たり、酷いのだとその部分以降ハイライタがぶっ壊れたりとか面倒な感じになったこともあったなぁ。
その辺clangに投げる方向に進んだのは慧眼だったんだなぁと。
てかコンパイラの対応表みてると、clangは先進的で突っ走ってるけどここ何年かはgccがきっちり追従してるのが変わったなぁとか。
c++11~17ぐらいまでは結構gccは対応遅かった印象なので。
それどころかc++26だとgccのが先に対応してるのとかあるし。
逆に最近はvc++がかなり微妙だったりで。
c++23の言語機能の方、ここ数年まったく進んでなかったりするし。
if constevalいつになったら使えるねん……。
でもc++23の標準ライブラリ機能の方はほぼ実装済みみたいで、そっちに全部のリソースつぎこんでる感じなんですかね。
c++26の方はまだぜんぜん白紙っぽいですけど。
ていうかinspectはまだ来ないのかなぁ。
次世代のswitch case文とも言うべきinspect。
CEDEC 2024『ゲーム開発者のための C++17~C++23, 近年の C++ 規格策定の動向』
ttps://www.docswell.com/s/cpp/5XEY92-cedec2024#p1
今回色々調べてた時に出てきたスライドなんだけども、新旧包括的に網羅されてるので、復習と新規の両方学べてとてもいいスライドでした。
……ただ、新規の方はvc++で対応してるのか調べながら見てたので全部見終わるのにえらく時間かかった……。
optionalのモナドとかもう使えるのかぁ……いつの間に。
めっちゃ種類あるのなrangeアダプタ。
便利だけども、空で使い分けられるかと言うと……どっかに一覧まとめて置いとくとかしないと適宜に使いこなせなさそうw
んで、ここの最後の方でちょっとinspectにも触れられてたんだけども。
なんかC#とかっぽく「as」キーワード入れたりとか「let」とか、書き方のところで意見が割れてたりとかでごちゃごちゃやってるらしい……。
んでc++29になりそうとか……うぐぅ。
とりあえずまあ現状c++で欲しいのは「inspect」と「c++26では削除されるcodecvtの代替」の2つが筆頭ですかね。
後者はほんとどうにかして欲しい。
だから未だにc++は文字周りダメダメだよねと言われるんだよ(ぉ
Qtでもunicodeの相互変換はできるけど、shift-jisが切られちゃって変換するのに困る感じになっちゃってるんですよね。
未だにzipフォーマットの中身の文字はshift-jis多いんだよ……。
まあwin環境に限ればWinApiで文字コード変換辺りはなんとかなってるけども。
でもできれば環境依存コードなWinApi使わないで済ませたいですよね。
そんな感じで、susie代替のビューワ、あとは細かい設定周りと設定画面のui辺り作ったらとりあえず完成かな。
んでも画像ファイルへの関連付けの仕方がwin10以降? から変わったけど、関連付けたファイルのアイコンの設定とかどうやるんだろね。
その辺まだ全然調べてもないや。
いまウチのpcだと、とりあえず代替で使ってた画像ビューワに設定して以降、bmpもjpgもpngもみーんな同じアイコンになっちゃってるんだよな。非対応のavifだけ違うアイコンになってるけど。
拡張子で細かく分けるのとかは、新しい関連付け方式の方だとどうやって設定するんだろね。
できればタイプ別で同じアイコンでも色違いとかにしたいなぁ。
そのへんも調べとかないとな。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
06
07
08
■
■
アウアウア
09
10
11
12
13
14
■
■
ドツボにはまりすぎてへん
15
16
17
18
19
■
■
なんか妙に時間かかったな
20
[春分の日]
21
22
23
24
25
26
27
28
29
30
31
total:2110016 t:71 y:52
■記事タイトル■
■年度別リスト■
2025年
2025年12月(0)2025年11月(0)
2025年10月(0)
2025年09月(0)
2025年08月(0)
2025年07月(0)
2025年06月(0)
2025年05月(0)
2025年04月(0)
2025年03月(3)
2025年02月(8)
2025年01月(3)
2024年
2024年12月(1)2024年11月(2)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp

