堕天使の煉獄

FileSeeker3の代替ツール開発。

とりあず完成ぽ。


前回の内容の更新案を色々盛り込んだりして、とりあえずキリのいい感じに放ったかなと。

タブの一時非表示化
親パス毎に掘るサブフォルダ階層個別指定（画像の[無制限]とか[+2]とかがそれ）
全体の検索ワード履歴

あたり。


しかしこのツール、なんか妙に時間がかかってしまったり。

ハマったのが、リスト内アイテムのD&Dでの移動。
え？　そんなん簡単やん。ハマる所ある？
って感じなのですが、以外にハマってしまったり。

ドロップ先の指定にdropIndicatorPositionなるものがあって。

QAbstractItemView::OnItem
QAbstractItemView::AboveItem
QAbstractItemView::BelowItem
QAbstractItemView::OnViewport

の4種類。

「OnItem」はアイテムの上にドロップ。
コレはmoveでなくswap、D&Dでアイテムの入れ替え動作をしたい時に使う感じかな。

「OnViewport」はアイテム上ではないビューポート上。
アイテムのない空白部分へのドロップってことですね。
無視するか、リストの末尾に移動に振り分ける感じか。

で、問題がAboveItemとBelowItem。

AboveItemがインデックスの上にドロップ。
BelowItemがインデックスの下にドロップ。

これが厄介だったりで。
リストアイテムとアイテムの間にD&Dするとき、よく見ると、アイテム間にドロップする場所が2箇所あるんですよね。
んで、AboveItemの場合はインデックスの上。
つまり、ドロップ対象アイテムのindexはドロップ位置の下のアイテムのインデックスに。
BelowItemの場合はドロップ対象アイテムのindexはドロップ位置の上のアイテムのインデックスになる。

通常、アイテムの移動は、QxxxWidgetなんかに標準でついてる機能でやれはこの辺上手くやってくれてる感じで気にしないでよいのですが。

別にデータリストを自前で持ってて、QxxxWidget上でアイテムの移動あったら、移動元と移動先のindexを取得して、データリストを自分で並び替えて、そのあとQxxxWidgetをデータリストを元に更新。

みたいな運用してると、この移動先のindexの取得がAboveItemとBelowItemによってずれるんですよね。

しかも面倒くさいのが、移動先が移動元よりも上にあるか下にあるかでAboveItemとBelowItemが逆動作になったりして。

で、そのへん整理して理解するの面倒くさかったものの、なんとか組み終える。
単アイテムのD&Dは。

問題は、複数行選択時のD&D。
移動開始位置アイテムを基準にすればあとは同じかなとおもったのですが、なんか上手くいかない。
なんか位置がずれる。
しかも2つとかズレたりして、なんかバグってないかコレ？
となって、しばらく考えた後、考えることをやめましたｗ

そもそも複数行選択でD&Dって、いるのかな？
となったりで。

結局複数行選択時は、全部「先頭に移動」か「末尾に移動」というのを追加することに。

そんな感じで、すっげぇめんどくさくて、ひとしきりぐじぐじ弄り倒した挙げ句、いかに楽するかという方向で終わらせる感じにｗ

んでも、普通のwinアプリの他のツール(ファイラー系)なんかで見てみたけど、アイテムとアイテムの間の移動先が2つに別れてるのなんて無いんですが。
普通に真ん中に一個だけしか無い……。

Qtはクロスプラットフォームなので、多分そういうシステムのOSがあるのかな。
それにも対応できるようにそうなってるのかもしれないぽ。



次にハマったのが、検索結果につけた、コンテキストメニュー内の「送る」。
標準のシェル使うと必要になるwindows.hともろもろをインクルードしたくないので、自前でsendToの中身を拾ってきて表示する方向でつくってるだけど。
動作的には問題なかったんだけど、表示に違和感が。
なんかメニューのアイコンのサイズが32*32になってるんよね。
他のwin標準の機能つかってるファイラーなんかの送るメニューだと、アイコンは16*16。

んで、QMenu内のアイコンのサイズの指定というのが、どうも普通には出来ないらしい。
なんでもメニュー内のアイコンサイズは、OSのスタイルを参照してるとかで。
なるほど、4ｋとかデカい画面モードなんかだと、動的にアイコンサイズなんかも変更する必要があったりして、それに対応するために、setIconSizeなんかでは設定できなくなってるのね。
そういうシステム寄りの機能ってことなのかQMenuは。

んでぐぐってみると、QProxyStyleでスタイルを上書きしてPM_SmallIconSizeで返す値を設定すればOSのスタイルを部分的に書き換えられるそうな。

……確かにサイズは変えられた。

ただし、デカくするのは出来たんだけど、何故か32*32→16*16と小さくしても32のまま変わらないという。

取得してるアイコン自体に16*16サイズがないのでわ？　そんな馬鹿なと思いながらも、取得したアイコンの内部で持ってるサイズを列挙する関数あるのでやってみると、ちゃんと16*16は含まれている。

んんーなんか何処かでサイズ制限かけられてる感じ？？
雰囲気的にはOSの元のスタイルを反映してるっっぽいのでそのへんかと思うものの、じゃあ普通に使ってるファイラーの「送る」のアイコンは16*16になってるよ？　ってなるし。

全くわからん……。

とりあえず、アイコンを一旦pixmapに出力して、サイズを16*16にした後、そのpixmapをアイコンとして登録(16*16しか存在しないアイコン)とすると、まあ16*16のアイコンで表示できるようにはなったんだけども……。

これってOSの設定なんかでスケーリングが変更された時でも、ここはハ－ドコーディングされちゃってるので16*16のちっこいアイコンしかでねぇよ？
となっちゃうので、あんまりよろしくない解決法だなぁ……。

この辺、内部でどうなってるのかとか調べてるだけでも数日経ってたりして。
まあ、わからない部分を解明していく過程で色々と知識も蓄えられていくので無駄ではないんですけどもね……それでも時間の浪費と徒労感は積もるわぁ……。


そんで最後のハマりポイントは、検索対象のパスとかファイルリストの管理方法、いつ何処で何をキャッシュするかとかそのへん。

この辺は結局いまだにどうするのがベストなのかまだ全然結論出てません。

タブ毎で検索対象パスリストを切り替える方式というのが問題を複雑にしてる感あったりもするのですがｗ

そこで、検索対象パスリスト自体はアプリ全体で一個共通で持つ……という方向にしたほうが管理は楽なのですが、無駄が多かったり、無駄を省こうと思うと結局複雑な感じになりそうだし……。

そんな感じで、スッキリしないモヤモヤな感じに。


んまあ、とりあえずここらでキリつけて次に進みたいかなと言う感じぽ。
しばらくは運用してみて使用感を確かめて……結局FileSeeker3でいいかってなるオチもあるんだけどね（ぉ

はふ～