堕天使の煉獄

あの後、結局明示的にshift-jis変換出来たほうがいいよなーってことで、windows.hをincludeする羽目に。
うーん、windows.hは大量のマクロで名前空間汚すからしたくないんだけどねぇ。
とはいえ、自前でshift-jisするのも昔作ったけど、速度的にも微妙（というかMultiByteToWideChar系が異様に速い）なのと安全性（へんなunicodeとか）も考えると、自前のはどうもなぁと言う感じで。

C++20のmoduleでどうにかならんものかなーとちょっと調べてみたんだけども。
moduleはマクロの名前空間汚染も閉じ込められるんですよね。
そしてwindows.hつかうものMultiByteToWideCharとか使いたいだけなので。

うーん。
できそうな、できないような？？
まだまだmoduleあんまよくわかってないのと、調べてみた結果、windows.hはいろんな副作用が多くて、単純にmodule化出来ないらしいというのがわかったぐらい（ぉ

あとは細々とした部分作ったりして、とりあえずソースコード覗くだけのツールは完成ぽ。

そのあとに、ハイライタの指定とかで、正規表現のテストするwidgetとかほしいかなーとおもって、さらにそこだけ抜き出してツール化したものも作ったりもしたんだけども……。

結局、web上である「正規表現チェッカー」のがさっと使えるので、あんまつかわないかも……となった（ぉ
まあ、正規表現でも内部のライブラリがおんなじQtのものでテストできるという利点はあるのだけども……そこまでそれが必要かというと？？

まあ、この手のは作ってるときは「これは捗るでぇ！」と思いながら作るんだけど、作った後では一度も起動したこと無い……なんてことはよくある話なので（ぉ


で、その次にちょっとした小物ツールを作り始めてて。



見る人が見たら、「ああ、あのツールのパク……代替品ね」と分かるものですがｗ

もうね、古いランタイムとか入れたくないでござる。
ていうとの、結構作りは簡単そうだったので作ってみたんだけども。

とりあえず設定読み込んで表示、各種コントロール（スピンボックス、コンボボックス）で値変更までは出来。
あとバイナリダンプなんかも追加してみたり。


あとはアンドゥ・リドゥとコピペまわり。
そして最後にアプリ設定まわり整えたら完成なんだけども。

アンドゥ・リドゥは作り的に1～4バイトのデータを読み書きするだけのコマンドしか無いので簡単なんだけども。（後述の3バイトの扱いでちょっとペンディング中）

コピペどうするべきかなーとちょっとプチ悩み中。

こういうテーブルのcolumn毎にデータ形式が違うものって、どうやるのがセオリーなんだろうなと。

とくに複数column選択コピー→貼り付けなんてとき。

column毎にデータタイプみたいなの設定して、それ同士が同じならペースト可能。
ていうのはぱっと浮かぶものの。
実際にはそんな単純なもんではなくて。

例えば1bitフラグ。
特定のbitが立ってるかのフラグデータなんだけども。
別の1bitフラグcolumnでは違うbitが条件になっているわけで。
そうなると、単純にコピー元のcellの値を保持するのでは駄目で「オン・オフ」の情報(bool)で持って、ペーストの際にはどのbitをオンにするのか参照して～みたいな処理いるのねーとか。

リスト形式の場合、リスト形式で4バイトの値を設定するみたいなフィールドの場合、4バイトのデータならデータタイプおんなじだからコピペできるよなーてと、リストは4バイト分のリストがみっちり詰まってるわけでもないので、リストの範囲外の値をペーストする可能性もあるわけで。

そのへん、どこまで許容して、どこまで規制するのかとか、そのへんのルールとかいうかセオリーがまったく定まってないぽ。
普通どうやってんだろ？

単純に経験不足ｗ


経験不足エピーソドとしては。
今まではせいぜい数十件＝数百件程度で完結するような小物ツールばっかつくってきたのでQxxxWidget系で十分だったんだけども。

今回のようなときには数万件(左側のバイナリダンプのとことか)のデータをテーブルで扱うとなると、QxxxView系、model/viewな方を使わなきゃいけないわけで。

そっち系あんま使う機会なかったからこれも経験不足なんだよなぁと。

んでも、バイナリエディタでよく見るバイナリダンプ。
いざ作ってみたら、めっさ簡単。
というかQTableViewが便利なんだなと言う感じで。
むしろテーブルの表示のstyle設定周りの方に苦労したぽ。


んで右側のほうはせいぜい数百件～数千件しかデータ無いはずなのに、異様に重い。
テーブル開くのに数秒かかる。
デバッグビルドだからか？　と一旦リリースに切り替えてみるも、ちょびっと早くなっただけで、やっぱりくっそ重い。
モデルビューなのになんでこんな重いんだ？？

原因は「QHeaderView::ResizeToContents」でしたｗ

cellの中身のサイズに合わせてヘッダのサイズを調整するオプションなんですけど、これ全テーブル走査するので数百件超えるようなのだと、爆遅になるぽ。
これ外したら普通にサクサク動くように。
数十件程度なら全然問題にならないんですけどね。
普通に地雷オプションじゃねーか……。
でも代わりに自分で幅の調整しなくちゃならなく……メンドイ。

とか、cellに表示するコンボボックスの横幅をセルのサイズに合わせつつ、内容がはみ出るときは内容に合わせて幅を拡張させる……とか。

いろんなノウハウが足りてない＝経験不足が色々露呈したなぁ。
ここ数日、ほとんどそういう部分の調べ物に時間食われてた感じ……。


他には、なにげに元の仕様的には3バイトのデータも扱うんだけども。
3バイト型というものは存在しないわけで。
なので4バイトの型で代用するのですが。

テンプレートで
template＜typename T＞
setData(const T& value, quint32 bitMask){...}

なんかやろうとしたらば……3バイトの型ないからテンプレートで分けれないじゃん……とかなったりｗ

仕様的には3バイトはあるけど、「実際にはほとんどつかわない」と解説サイトでもかかれてたんだけども。
調べてみたら一個だけ3バイト使ってるところあったよ……。

んでもこれって4バイトデータのところにビットマスクで0x00FFFFFFすれば4バイトとしてあつかえるのでわ？　となったり。
3バイトとか型で切り分けられないのとか不便でしょうがねぇ。
なので、3バイトは仕様的には廃止しようかなと。
現行3バイト指定のはビットマスク設定したのに置き換えるかんじで。

そいえば昔、共用体使って3バイト型作るみたいなのなんかで見たな。結局つくってはみたものの、実用性なくね？　で結論付けられてたけどｗ


それから、元のアプリのりどみの「今後の予定」のところに

「設定の仕様変更(主にビット関連)」

てのがあって。
まあ2006年で更新止まってはいるんだけどｗ

確かに今回つくてみて、ビット関連周りの仕様はもうちょっとなんとかスッキリ出来ないものか……って印象あるですね。
でも作り直してる手前まあ、じゃあどうすんだと言われても困るところではあるのですが（ぉ
確かに設定フォーマット的にも扱いメンドイ部分だなぁと。
無きゃ困る部分でもあるし。


最後の更新履歴にのところに「「ステップ」でビットを指定できるように変更」てのあるんですが。

正直めんどくせぇぇぇぇぇｌ！！
っていう仕様だったので、ステップでbit指定は「未対応形式」として弾くことに。

なんかbitの並びが、bit指定のほうでやれば横列並びになるのが、ステップにすると縦列並びになるのと、1バイト範囲跨ぐケースもあるので、なんか色々と面倒だぞこれ、となったので。
そして今のところ「ステップでbit指定」のケースまだ見たことないし、弾いても問題ないかなと。

あとは仕様書にない仕様とかどうするべきなのかなとかも。
.iniの中で.idnファイル指定あるけど、.idnファイルが存在しないケースとか。


んでもまあ、zip書庫なんやかんやするツールつくてたときもそうだけど、他人様が考えたフォーマットにしたがって作られたデータを仕様どうりに読み取ってそれが表示されるとなんかワクワクするよね。
お、ちゃんと読めてる読めてるって感じで。

そんな感じで今月中に終わるかな。
終わったらこれで久々にデータいじって、プレイしようかな。

元のアプリがランタイム無いでーって使えなかったのを鑑みるに、このPCになってからプレイしてないんだなーってなった。
結構間空いたなー。
定期てきにやりたくなるんですよね。
やっぱろまさが3は名作だなぁ（とおい目

なにげにいま、おやつ氏がサガエメのプレイ動画上げてるけど、サガスカ同様、同じ路線のサガエメ全く食指が動かなくて、一番最初のちょっと見ただけで興味なくしちゃったなぁ。

やっぱやりたいのはロマサガ3～サガフロ1～ミンサガ1路線なんだよなぁ……。

サガフロ2リマスタとかもなんか話出てきてるらしいけど。
サガフロ2は雰囲気ゲーって感じで雰囲気は良かったんだけどねぇ。
キャラが世代交代やらほぼ固定やらで、育成の楽しみとキャラ選択の自由が低すぎてハマらなかったんですよね。

はふ～

レス

お名前（無記入可)

本文

はー。
やっとソースコード見るだけのツールとりあえず出来た。
時間かかったなぁ……。



実作業時間だとべつに大した事無いはずなんですけどね。

Qt Creator立ち上げっぱなのに1行もコード書かない日のが多かったりするし（ぉ
モチベーションの問題なんだよな。
そもそも元々昔に作ったツールのリコンストラクトなので。

とはいえ、最初はQt4時代に作ったツールで、Qt5になったときにちょこっと修正＆ビルド通るようにプチ修正って感じで、ほとんどが古いコードのままだったので。
Qt4てと、まだc++11も……今ググってみたら2005年にQt4.0リリースか。
やっぱまだc++11以前の頃だよなぁ。

c++はｃ++11以降、かなり大きく変わったので、それ以前のコードだと書き換えないとしょうがないしなーと。

なので、ほとんど全面リライトすることになったんですよね。

あとQt5→Qt6でQTextCodec系が全廃止、文字コードshiht-jisがQtでは非対応になったという、結構面倒な破壊的変更あったのも大きいかな。

影響のある部分では、zip書庫をいじるツール。
世に出回ってるzipファイルって、まだまだ大多数、中身の文字コードがshift-jisなんですよね。
背景には世の中で使われてる解凍ツールが枯れてるせいか古いものが使われ続けて刷新されず、unicodeなzipファイル使うと古いツールだと開けない（マンガミーヤとか）のが現状で。

なので、zip書庫をなんかするツールだとshift-jis対応要るんだよなぁ……。
現状、日本語windows上で動かす場合、QTextCodec系の代わりに追加されたQStringConverterで、「system encoding」ていうのを選ぶとshift-jisになるんだけども。
これは環境依存なのでどの環境でもshift-jisになるわけではないので。
うちで自分が使うだけのツールならそれでもいいんだけどね。

でもosの内部コードもwin11以降になるとutf8に以降してるみたいな話もあるしで。
でもでも、いまだにレガシーなwindows周りのライブラリやツールってshift-jis依存べったりなんだよなぁ。

一応「Qt 5 Core Compatibility APIs」と、Qt6でもQt5時代のいくつかの古いAPIもサポートしてますよっていう追加オプションあるんですけども。
Qt7になったらどうなるの？　て感じだし。

shift-jisまわりはwinapi直叩きで自前で処理する部分作っとたほうがいいのかなぁ明示的にshift-jis使えるようにしたほうが、今後も安心なんだよな。

でもQtのプロジェクトにwinapiのライブラリのリンクとか追加するのなんか汚された感あって、なんかやなんだよなぁ……気分の問題か（ぉ

んで、さらに今回めんどくさかったのが、設定周り。
以前のは設定はコードに直書きの手抜き仕様だったのを、ちゃんと外部ファイルでせっていできるようにしたんだけども……。



設定画面のuiと機能作るのめんどくせぇぇぇぇぇぇってなったりで（ぉ

んでもまあいろいろと勉強にはなったかも。

この手のエディタの設定って、色やフォントの設定って、だーっと単一のリストで並んでる感じになってるんだけども。
んで、例えば正規表現でハイライタ設定なんかするときには、そこでプルダウンメニューがあってそこからカラー設定を選択するかんじで。

でも、そういう形式だと、プルダウンで選ぶときにどんなカラー設定になってるのとか見えないやん？

ってことで、上のような、設定毎にカラー設定widget設置する感じにしたんだけども……。
管理めんどい……コードも増える……。
あーカラー設定まわり単一のリストで管理すると、確かに管理面では楽なんだな。
そしてカラー設定の設定画面もそのリストのところに一個あれば済むわけだし。

でも単一リストで、ユニークID割り当てる感じだと、例えばサクラエディタなんかだと、「正規表現キーワード」が1～10まである感じで。

……まあ正直、そんな正規表現キーワード大量につくってもハイライタ重くなるし、実際にはせいぜい使っても3つとか多くても5つぐらいしか使わないんだろうけども……。

でも、ユニークID割当方式だと10を超える場合に困ったことになるというのはデメリットではある。

でもまあ、それを見越して10こで足りるって判断でそうなっていて、実際の使用感として足りてるわけでｗ

んでもやっぱ、正規表現の設定などのところで、カラー設定が見れないってのは不満な所ではあったので。

こういう感じにしてみたんだけども、もうちょっとなんかいい方法なかったのかなぁ……っていう結果に。

なんかデータ構造がいろいろとネストしたり設定画面とコードがいっぱい増えてめんどくさくなっただけのような……。

ユーザビリティは向上したとは思うんだけどね……。

でもこれが自分しか使わないツールなので、そこまで凝る必要あったのかと（ぉ

まあ、いい勉強になったという言い訳で自分を納得されている俺ガイル。


あとは、なんかQt6.7に上げたところで色々とスタイル周りなんかバグってる感じあって。
なんかデフォルトのパレットが初期状態で反映してないっぽい？？

で、Qt6.7.1で治ってるかなーと期待しているのですが。

当初の予定では22.05.2024リリース予定で。

したら5/3に繰り上がってて、やっぱバグってるから早めにfix出すために繰り上げたのかな？　とか想像してたのですが。

予定日が5/8になり、5/14になり……昨日アップデートきたかなーと覗いたら5/20予定に……元の5/22と変わんねーじゃねーか。

なんで繰り上げた？？
Qt Creator 13.0.1のリリース日5/8に合わせようとして、間に合いませんでしたって感じなんだろうか……。

繰り上げといて結局元の日とあんま変わんないって、なんかすんごいヤキモキさせられただけでとってもファッキン。


んースタイル周りなおってるのかなぁ。
そんな感じでまだデバッグビルドのみで、リリースビルドはまだいいかなと保留中ぽ。


という感じで、一応このツールは完成。
他のプロジェクトのソースを見ながら移植したり参照したりする用途で使うツールなので、これから捗る……筈。

次は一個小物ツール作って、そのあとzip書庫なんやかんやするツールの7-zip使用版（rarとかにも対応）バージョンアップつくって……。

どうせならほぼ内容的にはマンガミーヤのようなビューワ系とおんなじ動作（書庫ファイルの中身列挙して表示）なので、マンガミーヤの代替作るのもいいなーともおもってるのですが。

他の使っても結局マンガミーヤが使いやすいともどってきてしまうんだけども、unicode対応してないのが厳しいんですよね……。
なので作ったらこれも捗るなぁと思ってたりするんですけどもね。

でもはやく3DダンジョンRPGも作り始めたかったりもするし。

とにかく、少しずつでも進めていこう……作業してさえいれば前進しているわけだしね……。

はふ～。