堕天使の煉獄

今日も今日とてPG。

最近やっと涼しくなったなと長袖なんか着たら、10月だってのに昼間には室温30度超えの真夏日だったり、夜結構暖かかったので、今日は半袖でいいか……と風呂上がりに半袖Tシャツ着てたら、次の日の昼間、雨降ったってのもあったけどめっちゃ寒かったり。
ことごとく服と気温が噛み合わないｗ

そんなか。

とりあえず、FileSeeker3の代替ツールはちょこちょこ実用テストしてみたところ、そこそこいい感じぽ。

検索ワードの先頭に空白あると、空白区切りで複数のワード対応してる都合、前頭の空白が「＊」扱いで全ファイルヒット状態になったりするポカとかあったけどｗ
やっぱ実戦こそが最高のテストだね。

んで、気がついたらQt6.9.3が来てたんだけど、リリース情報見てみると、その一週後ぐらいにもうQt6.10がリリース予定だったりして。
なのでちょっと待ってQt6.10来たタイミングでアップデート。

んで、ついでにいくつかの自作ツールの修正アプデ＆リビルドもしてたり。


で、今やってるのは古くから使ってる音楽ファイル系単体再生用で使ってるuLilithのフェイスエディタ作成。

まあ、結構古いツールだし、いまフェイス作ってる人なんて居るんかいなって感じですがｗ

最近老眼進んで今まで使い続けてたフェイスが文字ちっちゃすぎて読めねぇ……ってなったのが契機なのですが、どちらかといえばQtの技術的テストのほうが本命だったりもする。

これはQt Creatorのデザイナのプロパティ設定リスト。


それなりに長くQtやってる人なら共感すると思うのだけども、このデザイナのところのプロパティ設定のwidget、こんなやつ標準コントロールで欲しいんですけど？　っていう。

で、わりと昔から折をみて挑戦してたりしたんですけども。
これがまた、単純な標準のコントロールの組み合わせじゃ全然作れないどころか、かーなーりディープな内部のアレコレ掘り返さないとおんなじようなもの出来ないんですよね。

んでなんとかそれっぽいの出来たっぽい。


なんかもう、色々とディープ過ぎてめっちゃ時間かかったけど。

StyleSheet適用すると、BackgroundRoleが無効化されたり、border指定しただけなのに、開閉ボタンが表示されなくなっちゃったり……。

基本、Htmlのスタイルシートだと、親から継承されてきたスタイルがあるとき、子で設定変更した場合、親+変更部分になるじゃないですか。

Qtのスタイルシートは、一部をsetStyleSheetで設定すると、それ以外の設定吹っ飛ぶんんですよね……一部のwidgetでは。
なんか内部の設定の順番的なもので、ある意味バグのような気がしないでもないのですが、中身が相当複雑な感じらしく、「破壊される場合があります」とだけ書かれてたりしてどないせーちゅんじゃいｗ

そんな感じの、よくわからない不具合というか仕様に悩まされ続けてめっちゃ時間かかったり。

結局、初期化ボタン追加するのもpaintイベントをオーバーライドして自分でボタン書いて、マウスイベントで押下時処理も自前で書いて……。

ツリービューの開閉ボタンは、StyleSheetでborder足すとボタンが消えちゃうので、QTreeView::drawBranchesなるメソッドをオーバーライドしてそこでボーダーだけ自前で描画……。
リスト内の分類ヘッダ的なの(上の画像でいうところの黒背景で「Prefence」て所)だけ背景色とか変えたいんだけども、StyleSheet使ってるとBackgroundRoleが無効化されるのでこれもまたQTreeView::drawRowなるメソッドをオーバーライドして、そこで該当行だけ自前で描画……。

ツリーの展開中のサイズに合わせてwidgetのサイズもfixする必要あるんだけども(スクロールバーの処理の関係上、開閉でサイズが可変するので調整しないといけない)素直に全体サイズを取れるメソッドがなかったり。
QTreeWidgetにはあるのに……QTreeViewだと無い。なんでや。
なのでちまちま上から数えて高さを計算してみたり。

とにかく、派生、オーバーライド、自前で描画、自前で計算のオンパレード。
ほんと、めちゃくちゃ面倒な作りなんだなコレ……。

コード書いてる時間よりも遥かに調べ物してる時間のほうが多かったりして。
まあ勉強にはなったけど……。

にしても、もはや増えた気がするレベルを超えて、Qt関係で調べ物するとQtのPython版の記事がかなりの件数ヒットするようになってうぜぇ……。

ていうか一時期はQtQuickが増えてきてうざい時期あったけど、最近は全くヒットしなくなったな。
でもなぜか、Qt6.10とかここ最近のリリースではQtQuick関連の新機能ばっかり紹介されてるんだけど……アレ何処で使われてるの？？
組み込み系とか？

全く最近検索でも引っかからなくなってきたので、QtQuickとか空気な印象なんですけど、世界の何処かでは熱い所あったりするんだろうか？？

QtQuickばっかりじゃなくて、QtWidgetの方でもdirectXでシェーダーとか簡単に使わせて欲しいんだけどなぁ。

Python版の方は、コードは概ねc++に置き換えられるので、役に立たないってことはないんですけども、いちいち置き換えるのが面倒くさいぽ……。

んーでも、日本人＆日本語でQtの話題とかも、最近はあんま見ないので、将来とかどうなんでしょねｗ

最近ではスマホ環境向けとの統合がメインストリームな感じなので、ｃ++でwinアプリ専用開発みたいなのは、かなりニッチなジャンルになりつつあるからなぁ。


ちょっと関係ある話だけど。

uLilithのフェイスエディタ、何年も前に一度作りかけて頓挫したのですが。
その時のコードを参照して、思い出しながら組んでる感じなのですが。
とりあえず、何が必要なのかみたいなものは出揃う程度には組んであったので、今回組むにあたって、その分はかなり時間短縮出来てるぽ。

で、その中でフェイスの定義ファイルのI/Oのあたりのコードにこんなコメントが。

どうもUTF-8 BOM付だとダメっぽい
bom無しだといけるっぽいけどShift-JISと文字コード判定とかしてるのかな？？

uLilith自体かなり古くからあるツールなので、定義ファイルも文字コードがshift-jisなのがスタンダードだったりするのですが。

もう当時の事は昔過ぎてあんまり覚えてないのですが、文字コード変えて保存して読み込めるかテストした調査結果だと思うのだけど。

うーん。
shift-jisとutf-8の判別って100％には出来ないんですよね。
んで基本的にはascii範囲はどっちもおんなじバイナリになるのですが、こんなコメント残してるぐらいなので、日本語周りもshift-jisとutf-8(bom無し)どっちも行けたので、自動判別してるっぽい？
とか言ってるとおもうんだけども。

なので、今回改めて調査。
……あれ普通にbom付きutf-8行けるぞ？

わりとwinだとbom無しutf-8は鬼門なので(古いアプリなんかだとshift-jisが現役なので混ぜるな危険)できればutf-8ならbom付きを採用したい所。
てかまあ、面倒なのでutf-16をデフォルトにしたい所ではあるけど、bom付きutf-8使えるようになってるのなら無問題ですね。
当時以降のアプデで出来るようになってたっぽい。


んで、それとは別に調査の過程でとっても面倒な事態が。

uLilith上で「フェイスの変更」すると強制終了するようになってるｗ

それ以外の機能は一通り試してみたけどクラッシュせず。
色々調べてみると、window10である時期のアップデート以降、その症状が出たみたいな情報が。
どうも、vc++のランタイム周りの問題らしい。
uLilithの現行最新版はｖｃ++2019のランタイムが必要らしいのだけども、msさんのサイト見に行ったらば、いまは2015～2022までのがセットのバージョンしか無い＆すでにうちのPCには最新版のランタイム入ってるっぽいんですが……。

詰んだなコレw

エラーログ見てみると、ucrtbase.dllでBEX64がエラー吐いてるらしい。
そのへんでぐぐってみると、なんか古いエロゲでそのエラーが出て動かないんですが。
と、結構硬めのサポートフォーラムみたいなところでエロゲのタイトルがいくつもでてて、なんかシュールな光景が広がってるとこにぶち当たったりｗ
そして質問者の、エロゲタイトルをなんの躊躇もなく書き込んでる清々しさにちょっと
漢らしいと思ってしまったりｗ

そこではなんかファイル名に日本語混じってると駄目みたいな話が出てたりで。

最近はwindowsも内部コードがutf-8に以降するみたいな感じで、なんかある時期のwindows10のアップデートでそのへんのなんか変更したみたいなのあったなぁと。
なんかタイミング的にもそれ関係での不具合のような気がしないでもない。

うーん。
フェイスの切り替えが本体から出来ないんじゃテストもクソもないし、もはやソフトの寿命とも言える感じか？
最新版っても2019/12/07が最新版なのですでに約5年前だしなぁ。

uLilithのexeある所のConfig/uLilith.cfgの中に「LastFace = ...」て箇所あって、そこのパス変えたらフェイスの変更は一応出来たけど……。

……そういえばuLilith上からフェイスを切り替えるコマンドとかあった気がするな。
調べてみたら「ShowFaceSelector」と「ShowOpenFace」コマンドなるものが。
前者の「ShowFaceSelector」が、uLilith上で右クリックメニューからのフェイスの変更で呼ばれるフェイスセレクターを起動コマンドで、「ShowOpenFace」は定義ファイルを指定して読み込むだけのダイアログを開くコマンドらしい。

で、後者の方だとダイアログは開くし、選択したフェイスに切り替えも出来る！

どうやらフェイスセレクター内の、ツリー表示か、フェイスのサムネ表示あたりの処理でvc++ランタイムのバージョン問題が発生してクラッシュする感じっぽい。

デフォだとなかったので、「ShowOpenFace」コマンドを実行するショートカットキーを設定して、とりあえずuLilith上からフェイスを切り替えることは出来るように。

ただ、この方法だと、定義ファイル選択で開く最初のフォルダがexe直下の「Face」フォルダ固定のようで、フェイスのテストしようと思ったら、その場所に入れとかないと面倒くさい感じに……。
まあ、このぐらいなら許容範囲内かなぁ。

何にせよ、やっぱ古くて開発も止まってるツールだとこういう問題がポコポコ出てくるよね……。

そして、もとの話に戻るけど、今どきc++でアプリ開発とか、かなりニッチな世界になっちゃったなぁという現実を突きつけられるなぁとｗ

ほんと、最近はフリーソフトの開発者さんとかめっきり減ったものな。

そんな感じで……特に公開するつもりもない、自分で使うためのツールとかもりもり作ってるけど、生産性？　っていうワードが脳裏をよぎるたびに頭をブンブン降る毎日です（ぉ