堕天使の煉獄

一段落ついて、一眠り～としてたら、横になってふーと一息つくと、やっぱ出てきちゃうんですよね。あそこはこうしてれば、とか、あそこはこうすべきだ～とか。

そんな感じで、結局１から組み直しとかすることに（ぉ

まず、もう統合アーカイバ系のDLLは最初から使わない方向で。書庫ファイルかどうかのチェックも、アーカイバ内ドキュメントみるに、チェックの強度で、「標準」てのが、ヘッダのチェック。これは多分。localヘッダとcentralヘッダの重複部分のチェックだとおもわれ。これは普通に自前の読み込みルーチンの中でやってる。チェックの一番キツイ奴でも、ヘッダ内のcrc32の項目の値と、圧縮ファイルのcrc32の値を再チェックするという項目が増えるぐらいのもののようで。それは現状自前のではやってないんですけど（ファイルデータからcrc32の値取得するのってどのくらいコスト掛かるのかもよくわかってないってのもあって）とにかく、その辺ももう、自前でやってるんだなとおもうと、もう完全にアーカイバDLLいらんやん。ってことに。

んで、それをパージすることで何が得かというと、windows.hをインクルードしなくて済む用になるということ。
windows.hインクルードすると、大量のdefineマクロが追加されて、名前空間をレイプしやがるので、出来ればしたくないものであります。
vcだとそこまで気にならないのですが、Qt creatorだと、ファックされた名前空間からどばどばと使うあてもない候補が並んで、欲しいものを探すのに苦労する（そうならないように細かく名前空間とか別けてるのに…）のがなんともファッキンです。

で、それでアーカイバDLLつかわなければwindows.hも使わなくていいなーとおもったのですが。もう一個windows.hが必要なもの内部で使ってたのを思い出す。

……ゴミ箱。

ファイルを削除するときに、ゴミ箱にいれるっていうのは、windowsのshellの機能とかなんとかで、windows.hとともにShellAPI.hのインクルードが必要で、そんでまたなんとも使いにくい仕様のSHFileOperationとかいうAPIを使わないと、ゴミ箱にファイルを捨てる事が出来ないという。

で、アーカイバDLLパージしたのに、ゴミ箱の所為で結局windows.h外せないのかよ。とかおもったのですが、そこで、そうかこれ、コマンドラインでファイルパス渡して、渡された物をゴミ箱に放り込むという別アプリにしてしまえばいいのかと。

……windows.h使いたくないだけのために、exeにファイルをドラッグするとファイルがゴミ箱に捨てられるだけのアプリを組むとか、なんだかなぁ……な感じですが。でも今後もＱＴつかうんならまあ便利かなと言う気も。

で、いざ作ろうと思ったところで。
うまく動かない～。

exeファイル単体にエクスプローラ上でファイルをドロップするときはちゃんと動くんだけど、ＱＴ上でQProcessから実行すると、「QProcess: destroyed while process still running」とかでたうえで、ゴミ箱にファイルはいらなーい。

なんかプロセスが終了出来てないのに終了しようとしたよ？　ってきなメッセージだとおもうのですが。
コンソールアプリの最後はgetcharでキー入力待ちしてるのだけど、それはcloseWriteChannelというもので回避出来るはずなので、自動でプロセスは終わってるはずなんだけどなぁ……。

QProcessでは別プロセスを開始するのに、startとexecuteそれにstartDetachedと
いうのがあって、startは子プロセスとして。startDetachedは独立したプロセスとして起動するんだとか。executeはstartとなんか違うらしいのですが、サンプルが見つからなかったのでよくわからず。

とりあえずstartDetachedに変えてみたら、コンソールが表示され、ゴミ箱にファイルを送れるようにはなる。

が、なんかおかしい。
動作的には、書庫ファイルの中身編集した結果を、メモリバッファ上にファイルイメージを構築。それが終わったら、元ファイルをゴミ箱にすて、元ファイル名と同じ名前をつけてメモリバッファ上のものをファイルとして保存。
てな感じの上書きプロセスなんだけど、実行してみると、ファイルがゴミ箱に行くだけで、元ファイル名のファイルは保存されてない。

……というか、「上書き保存」の後に「ゴミ箱に捨てる」が実行されてるっぽいｗ

完全に独立した別プロセスだとこうなっちゃうのか……ｗ
ウェイトかけるてのじゃ確実性に欠けるし、動作も遅くなるしなぁ。

あと、コンソールも表示されないのが期待動作だったのだけども、なんでか出てるなと。おなじコンソールアプリのUnifyZipはコンソールでないのになんで？

で、そもそも、思い違いをしてたのが、何も表示されないアプリ作るのって、コンソールアプリじゃなくて普通のwin32アプリを使うのが普通なのですね……。単純にウィンドウを表示しないアプリを作ればよかったのか。
エラーの時はメッセージボックスつかえるので、標準出力とか使わないで良いし。
そんでもって、実行ファイルのサイズも、コンソールアプリだと300kbぐらいだけど、win32の場合は80kbぐらい（ｖｃのランタイムの依存度が高いんだろうな）

なんか、ウィンドウも出さない、極小のプログラムを書くときは、コンソールアプリ。っていう先入観もってたなーと。

で、win32アプリでゴミ箱exeつくってQProcessで実行してみたところ。
普通にstartで期待道理の動作に。ちゃんと終わったら勝手にちゃんとプロセスも終了してくれてるっぽい。

これで晴れてwindows.hの排除に成功～。これまたへんな回り道しちゃったなぁ……。


あとは、レイアウトの見直し。
やっぱ画像のプレビュー画面が小さい。
しかし、今まで使ってた書庫ではなく普通にファイルを追加するタイプの画像編集ソフトでは、設定画面がメニュー→設定で開いて設定して、その画面は閉じたあと、編集後の状況が見えるって感じの作りで。

やっぱ編集設定見ながら、設定適用後のものをみたい。設定変えたら即反映。
ってのがやりやすいなというのがあって、そういうレイアウトにしてたのですが。
プレビュー画面の幅を圧迫しちゃうなーと。

一応画像プレビューは拡大縮小もできるのですが……いかんせん、QGrahicsVeiewの拡大縮小はえらく汚いんですよね。一番クオリティの高いやつえらんでもこれ。アンチェリつけるオプションとかもあるけど、つけても汚い画像がぼやけるだけというありさまｗ
なので完全にプレビュー専用ですねこれは。
適用後の画像（リサイズ後）なんかは、リサイズ処理した後の画像をQGrahicsVeiewに再設定するので、100％表示のときは、編集結果も普通に綺麗に表示されるから、そこまで気にする物でもないのかもだけど。
この辺は本気で対応しようとするとかなりめんどくさそうぽ……。

でも、やっぱ編集設定画面は表示しつづけたい。
レイアウトの範囲の取り合いになってる感じでどうしたモンかなと。
そこで、編集設定は別窓で表示することに。モードレスな子ウィンドウで。
それなら消したいときにいつでも消せるし、表示場所もサイズも変えられるし。プレビュー画面も大きく取れるようになるし。


んでもって。

実際運用してみて感じたのが、複数の書庫を放り込むと、解析中にかるくハングる。ＱＴは処理待ちで長時間とまると落ちる仕組みになってるらしくQApplication::processEventsをちょいちょいよびだしてイベントを処理してやらないといけないらしい。
が、それで落ちなくなっても、処理待ちの間は応答不能になるので、これもやっぱ別プロセスで読み込み部分は作るべきだなと。
そうすれば読み込みの進行度とかもプログレスバーで表示とか出来るし。

それから登録する書庫ファイルリストはそんな登録しないので良いとして、書庫内のファイルリストを表示する部分は、数十程度なら気にならないけど、数百ファイルとなると、リストの更新がもっさり。

QTableWidgetでなく、QTableViewに変えるべきだろうな。ファイルリストのほうは。
両者の違いは、後者はモデルとビューが別れている、いわゆるMVCってやつですね。なので、データの量がどんだけ増えてもそれほど重くならない。
前者のは、更新の毎に前アイテム構築しなおすので数件とか数十件程度ならそれほど気にならないけど、それ以上になると、かなり厳しいです。
てかこの辺は実のところ、とりあえず今は前者のパターンで。
うまく全体的に動くの出来たら後から置き換えようと思ってた部分ではあるのだけども。
一旦モデルビューにしてしまうと、後からデータ構造の変更とか面倒なので。
先にとりあえず作っちゃってから変更の余地無くなったところで置き換えぐらいが面倒少ないかなというところもあって、残してた部分でもあるのですが。
やっぱ実際に数が増えると重い……。


とかまあ、ちょいちょい修正案も多く。
いつになったら終わるねん。という感じに。

あとはなにげにやっぱファイルサイズがすごいなと。
書庫編集アプリのexe自体は380KBぐらいと、そんなでかくもないのですが（小さくもないけど）
ＱＴのランタイムも含めると、38MBに。

１００倍だー！（野沢雅子調）

ちょっと作って配布～ってのにはでかすぎるなぁ（いやいまのところ配布とかする予定もないですけど）

そもＱＴのランタイムなんて、ＱＴ開発やってる人以外のＰＣにはまずはいってないし。ランタイムのｖｅｒ互換もないので、実行ファイルと同じ場所にランタイム同梱てのが最近は標準っぽいし。

その辺もいまいちＱＴの普及しない一因なのかなーとか。