site logo
新規投稿
*オープンクローズ
 + 
#
thilmera project - forum
不具合
[Closed] フォーラムが正しく表示されない
25 18:09[2 New]K
報告
[Closed] 「マウスオーバー非表示」をOFFにしてもしばらくthilmeraが表示されない
15 19:39[29]elphe
報告
[Closed] 起動時の重要なお知らせがメインディスプレイに表示されない
14 22:11[3]uhokun
不具合
[Closed] GPUのファンが表示されない
13 08:35[11]キャシー
報告
[Closed] 「マウスオーバー非表示」がONでマウスオーバーしても非表示にならない
12 20:24[4]elphe
報告
[Closed] ウィンドウ位置が固定されない
11 18:40[5]elphe
不具合
[Closed] `縦幅最大` を有効にしていても高さが目一杯にならない
10 17:16[4]tksk
不具合
[Closed] 起動できなくなった
07 23:55[4]さすけ
要望
[Closed] ネットワークI/O、通信量カウンタの表示単位について
06 00:46[2]TomSato
不具合
[Closed] CPU使用率などのゲージとシルメラの表示位置について
05 18:40[15]さすけ
不具合
[Closed] WIndows11のディスプレイ設定変更時のウィンド消失
03 20:58[13]retsam
不具合
[Closed] 論理ドライブ表示の設定が保存されない
02 09:25[2]キャシー
不具合
[Closed] PC起動時にウィンドウ最前面が維持されない
01/30[7]ナセル=フェレロ
不具合
[Closed] Win7でGPU情報をうまく取得できない
01/25[14]bnmr
報告
[Closed] GPUグラフ、タコメーター
01/23[5]タスマニアの悪魔
報告
[Closed] [半透明ウィンドウ]の[ウィンドウの透明度]がリアルタイムに変更されない
01/23[2]ANACOSTIA
報告
[Closed] スタートメニューへフォルダが自動的に作成される件
01/22[3]七海灯
不具合
[Closed] version 0b180 refresh r20 にアップデート後GPUの温度表示異常
01/21[2]ちゃっぺ
不具合
[Closed] 論理ドライブ表示周りの不具合(と思しきもの)
01/21[6]elphe
報告
[Closed] ディスクIO一覧が表示されない
01/21[15]タスマニアの悪魔
*オープンクローズ
 + 
#
thilmera project - forum
[Closed] 不具合 フォーラムが正しく表示されない
#1028
New K - 2222@Hy4II48W 返信 2024/02/25 17:43
このフォーラムですが,右コラムにもフォーラム内容が表示されてしまい,新規投稿する場所も右コラムになってしまっているので修正をお願いしたいです.

New Gakuto Matsumura - Developer 返信 25 18:00
おお…すみません。
昨日の夜に変更したサイドオーバーのタイムラインをTwitterからBlueskyのインラインにしたものが、フォーラムの場合に相対位置がずれて誤作動していたようです。

直した上で、フォーラムページでタイムラインが横に書かれている必要なさそうと思ったので、とりあえずフォーラムでのTLサイド表示は常時オフに変えました。

New K - 2222@Hy4II48W 返信 25 18:09
正常に戻っているのを確認しました.ありがとうございます.

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 「マウスオーバー非表示」をOFFにしてもしばらくthilmeraが表示されない
#1021
elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 返信 2024/02/11 19:15
#1020のテストビルドで行うと再現しやすいです
1. thilmeraのメインウィンドウを画面右端(タスクトレイの上)にもってくる。
2. 「縦幅最大」、「マウスオーバー非表示」をすべてONにする。
3. タスクトレイからthilmeraを右クリックし、そこからthilmeraをマウスオーバーで非表示にしながら「マウスオーバー非表示」をOFFにする。
4. thilmeraが現れない。マウスを離してもthilmeraは現れない。(不具合)
5. どこかをクリックするとか他のウィンドウを召喚するとかデスクトップに切り替えるなどするとthilmeraは現れる。(「ウィンドウ最前面」がOFFの場合は他のウィンドウの後ろに隠れることがある)

Gakuto Matsumura - Developer 返信 11 23:08
ありがとうございます。

確かに再現できたのと、それは想定してなかったので、とりあえずマウスオーバー非表示をオフへと切り替える時に通る場所で、マウスオーバー非表示に関するフラグをリセットして、ウィンドウを表示させるのと同等のコールも行うようにしました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240211-230453.zip

副作用でそうな気がしないでもないですが、設定変更時、かつオフへの切り替え以外は通らない所なので、多分いける…と思います。

変更内容:
 ● マウスオーバー非表示の設定を、非表示状態でオフに切り替えるとウィンドウが戻ってこない問題で、オフ時にウィンドウ表示をリセットして表示するように変更

elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 返信 12 01:09
thilmeraが現れない不具合の解消は確認しましたが、少し奇妙な挙動がありました。
仕様かバグかわからないのでとりあえず報告しておきます。
1. 「ウィンドウ最前面」「ウィンドウ最背面」「マウスオーバー非表示」をOFFに、「アイコンクリックでアクティブにしない」をONにしておく
2. thilmeraのメインウィンドウに他のウィンドウを重ねるように配置し、thilmeraのメインウィンドウの一部または全部を隠すようにする
3. ここでタスクトレイのthilmeraを右クリックしても、thilmeraの隠された部分は隠れたままである
4. このままマウスカーソルをthilmeraのメインウィンドウ上(であった場所)で「マウスオーバー非表示」をONにし、そこからマウスカーソルを離すとthilmeraが前面に引きずり出される
5. 元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠しても、thilmera(があった場所)をマウスカーソルを近づけたあと離すと再びthilmeraが前面に引きずり出される
6. 再度thilmeraを隠しても、タスクトレイのthilmeraを右クリックするとメインウィンドウが前面に引きずり出される(3.と挙動が違う)

6.の症状は、4.でthilmeraをマウスオーバーしながらでなくても「マウスオーバー非表示」をONにすると発生します。

Gakuto Matsumura - Developer 返信 12 19:22
ありがとうございます。

以下にて変更の内容
・「アイコンクリックでアクティブにしない」の設定がある場合に、アクティブ化してしまうルートの調整(スクリーンショット関連でのハンドリングは現行のまま)
・「ウィンドウ位置リセット」「最小化」「元に戻す」などで、マウスオーバー非表示関連での一時フラグをリセット
・関連して見つけた、「アイコンクリックでアクティブにしない」設定で、「ウィンドウ位置リセット」をしても他のウィンドウの裏に隠れて見えない問題で、フォアグラウンド復帰を必ずコールするように変更

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240212-191803.zip

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 返信 12 20:10
とりあえず暫定的な報告をしておきます。書き忘れていましたが、OSはWindows10です。
1. thilmeraを画面右下(タスクトレイのすぐ上)に配置する
2. 他にも色々ソフトを常駐させてthilmeraのアイコンを「∧」みたいな表示のところに押し込む
3. 「マウスオーバー非表示」をONにする
4. thilmeraの設定ウィンドウを出しておく(5.と6.のせいで右クリックメニューからは「マウスオーバー非表示」をOFFにできなくなる可能性があるため)
5. タスクトレイアイコンを右クリックして右クリックメニューを出そうとすると、出ないことが多い
6. 右クリックメニューが出ても、thilmeraが表示されていた領域からマウスカーソルを離すと右クリックメニューが消えてしまう

おそらくこの挙動の大きな原因は「マウスオーバー非表示が終了すること」だと思われます。
実はこれまでのバージョンでも、マウスオーバーでthilmeraを非表示にしながらタスクトレイアイコンを右クリックすると多くの場合一瞬だけthilmeraが表示されたのち「マウスオーバー非表示」が適用されて非表示になっていました(極めて軽微な、許容すべき不具合と判断してこれまで報告していませんでした)。これが6.だけでなく5.の症状を引き起こしていると考えられます。

Gakuto Matsumura - Developer 返信 12 21:14
こちら、一応試してはみたのですが、どういう問題なのかよくわかりませんでした。

上記の問題再現にはもう少し情報がいるようです。
たとえば、「∧」みたいな表示に入れる入れないに関わらず、「アイコンクリックでアクティブにしない」の場合、アイコンの左クリック右クリックで、他のウィンドウの後ろにある場合に表に出てこないのは、今回の修正の影響によるものですが、これは意図的なもので、正しいです。

おそらく、現象の再現に必要な要素が、「∧」みたいな表示のところに入れるか入れないかで変わる、カーソルとメニューとメインウィンドウの位置関係の問題かと思いますが…

まず、「アイコンクリックでアクティブにしない」の場合に、他のウィンドウの後ろにいた場合に表にはでてこないようにした。という前提を踏まえて、再度この問題がどういう問題なのかと、どういう挙動が望ましいのかを教えてほしいです。

Gakuto Matsumura - Developer 返信 12 21:17
補足として、「ウィンドウをアクティブにしない」という条件を維持したまま、後ろにあるウィンドウを前に持ってくるのは難しいようです。

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 返信 12 22:10
すみません、こちらのスレッドでも言葉足らずでした。

つまり、「特定条件下で右クリックメニューが強制的に消されてしまい、右クリックメニューが使えない」という別の不具合のせいで今回の修正内容(の一部)を確認できなかった、ということです。
タスクトレイアイコンを右クリックしたあと、マウスクリックしてもないのに右クリックメニューを強制的に消されることがないのが望ましい挙動です。

しかし、どうやらそちらの環境では発生していないようですね……
とりあえずこちらの環境で問題が発生しているiniファイルを添付しておきます。

[appended] ini

Gakuto Matsumura - Developer 返信 12 23:46
ありがとうございます。

最新のiniと前記の内容を合わせて試すと再現に成功して、メニューを開いた状態でマウスオーバー非表示を通過させるとメニューが消える。という現象の修正を試みてみました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240212-234355.zip

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 返信 13 01:53
右クリックメニューが満足に使えるようになりました!
また、タスクトレイアイコン右クリックでthilmeraのメインウィンドウが全面に引きずり出されなくなったのを確認しました!

ただ、「マウスオーバー非表示」をONにした後マウスカーソルを動かすとthilmeraが前面に引きずり出される挙動は残ったままです。以下に手順を記します。
1. 「ウィンドウ最前面」「ウィンドウ最背面」「マウスオーバー非表示」をOFFに、「アイコンクリックでアクティブにしない」をONにしておく
2. thilmeraのメインウィンドウに他のウィンドウを重ねるように配置し、thilmeraのメインウィンドウの一部または全部を隠すようにする
3. タスクトレイアイコンの右クリックメニューから「マウスオーバー非表示」をONにする
4. 他のウィンドウをアクティブ化せず、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、thilmeraが前面に引きずり出される
5. 元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠しても、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、再びthilmeraが前面に引きずり出される
6. この状態で元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠そうとしても、そのウィンドウはアクティブ化されたままなのでそのウィンドウではthilmeraを隠せない
7. 他のウィンドウを召喚すれば隠せる
8. でもthilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される
9. 最初thilmeraを隠していたウィンドウを再度アクティブ化するとthilmeraはそのウィンドウに隠されるが、もう一度thilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される

Gakuto Matsumura - Developer 返信 13 02:00
最終の添付されたiniと、上記に従ってみましたが、再現できませんでした。

メインメニューからマウスオーバー非表示への切り替えを、ウィンドウ範囲内と範囲外の両方試してみて、何度か、とあったので何度も往復してみましたが、とくに前面にでることはありませんでした。

ウィンドウの切り替え対象としてテストを行ったのは、Thunderbirdというメーラーで、ワークエリア全面のノーマル配置です。

上記の比較対象となっている切り替え先のウィンドウは、対象が何であっても起こりますか?

もう少し情報が必要なようです。

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 返信 13 02:32
こちらが切り替えウィンドウとして試したのはFirefox, Thunderbird, VSCode, エクスプローラー(Windows10標準), 設定(Windows10標準)で、ウィンドウが最大化されているかを問わず発生します。往復の回数は最少で1往復、確認されたものの中で最多でも9往復でした。1~3往復が最も頻繁な印象で、7往復以上はかなり稀です。

あまり設定は変更していないつもりですが、最新のiniファイルを添付しておきますね。

[appended] ini

Gakuto Matsumura - Developer 返信 13 11:20
最新iniにて再度試して再現できました。

最新の問題の解決と、解決した場合は、関連して副作用の問題がないか確認をお願いします。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240213-111935.zip

Gakuto Matsumura - Developer 返信 13 11:39
あぁ、根本的な原因が新たに見つかり、他での修正要望により、一部環境にてスタートアップ時の実行で見える状態で開始されない問題への対処にかかってくるようです。

両立させられる手段があるか試してみます。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 返信 13 11:55
どうやら解決していないようです……
>1. 「ウィンドウ最前面」「ウィンドウ最背面」「マウスオーバー非表示」をOFFに、「アイコンクリックでアクティブにしない」をONにしておく
>2. thilmeraのメインウィンドウに他のウィンドウを重ねるように配置し、thilmeraのメインウィンドウの一部または全部を隠すようにする
>3. タスクトレイアイコンの右クリックメニューから「マウスオーバー非表示」をONにする
>4. 他のウィンドウをアクティブ化せず、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、thilmeraが前面に引きずり出される
>5. 元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠しても、thilmera(があった場所)にマウスカーソルを何度か出し入れすると、再びthilmeraが前面に引きずり出される
>6. この状態で元々thilmeraを隠していたウィンドウをアクティブ化して再びthilmeraを隠そうとしても、そのウィンドウはアクティブ化されたままなのでそのウィンドウではthilmeraを隠せない
>7. 他のウィンドウを召喚すれば隠せる
>8. でもthilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される
>9. 最初thilmeraを隠していたウィンドウを再度アクティブ化するとthilmeraはそのウィンドウに隠されるが、もう一度thilmera(があった場所)にマウスカーソルを何度か出し入れすると、またthilmeraが前面に引きずり出される
このうち変化したのは、手順4.と5.と8.と9.で「何度か」から「一度で必ず」になったこと、手順4.を経由してもしなくても手順5.や手順7.に移れるようになったことです。

また、「マウスオーバー非表示」がONの状態でタスクトレイアイコンを右クリックすると、その後他のウィンドウをクリックしても右クリックメニューが消えず、thilmeraのタスクトレイアイコンを右クリックしても右クリックメニューの表示位置は全く変わりません。右クリックメニューを消すにはメニューから一つを選択するしかなくなります。

[appended] ini

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 返信 13 11:56
>あぁ、根本的な原因が新たに見つかり、他での修正要望により、一部環境にてスタートアップ時の実行で見える状態で開始されない問題への対処にかかってくるようです。

>両立させられる手段があるか試してみます。
すみません、このコメントが見えていませんでした。

Gakuto Matsumura - Developer 返信 13 12:47
懸念していた別の問題への修正に関しても調べてみましたが、どうもそれでもなく、さらに根本的な部分にあるようです。

ためしにマウスアクション系の非表示から復帰時のウィンドウのコール方法を変えてみましたが、今度はカーソル端設定、またはマウスオーバー非表示+カーソル端表示、全画面非表示で一切表にでてこなくなり、用途からすると明らかにおかしくなってしまいました。

マウスアクション系は、マウスオーバー非表示、カーソル端表示、全画面非表示のそれぞれの組み合わせ、かつそれぞれのトグルありなし。かつそれぞれの最前面、ノーマル、最背面に対して、各々の使い方をしているユーザーの互換性を考慮しないといけません。

0b180の修正開始から、これらの修正をしては別の人の修正がはいり、その修正が修正の必要性を起こす。というのを繰り返していて、どれもがそれぞれの人の環境でしか確認しづらい。というのが今の流れで、問題となっている点も、これらの修正の影響も多く含まれています。


なので、今回の最新の問題は不具合の修正ではなく、全く別の新たな要素として、「マウスオーバー非表示からの復帰を非アクティブで行う」という設定を追加して分岐するしかなさそうです。



>また、「マウスオーバー非表示」がONの状態でタスクトレイアイコンを右クリックすると、その後他のウィンドウをクリックしても右クリックメニューが消えず、thilmeraのタスクトレイアイコンを右クリックしても右クリックメニューの表示位置は全く変わりません。右クリックメニューを消すにはメニューから一つを選択するしかなくなります。

こちらは全く別の問題で、対象のウィンドウが非表示であるからですが、ここはOSの挙動との兼ね合いなので、これもどうすればよいのかは難しい所です。

そもそもウィンドウが非表示なのだから根本的解決はしようがないので、こちらの問題の対策方法として、マウスオーバー非表示をウィンドウを非表示にせず、モニター範囲外にとばしてそこで待機させる仕様。という案もありますが、これはやりだすとあまりにも根幹の変更すぎて、現在の修正フェーズではなく、新バージョンの作成+長期間テストな感じかなと思います。

Gakuto Matsumura - Developer 返信 13 13:35
ひとまず、設定による分岐を作成しました。
マウスオーバー非表示のオプションとして、「非アクティブで復帰する」を追加しました。

内容としては、これをオンにすると、マウスオーバー非表示などから復帰する際に、前面に出てしまうのをほぼ防ぐことができる。

今までのユーザーの使用と互換性がないので、デフォルトではオフ設定。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240213-133300.zip

以下既知の問題は、次回以降の新たな開発時での対処とします。
・「アイコンクリックでアクティブにしない」でのメニュー動作
 この設定がオンの場合、タスクトレイアイコンからメニューを開いて、メニュー以外をクリックしても、メニューは閉じられません。
 この挙動は、メニューの元となるウィンドウがアクティブではない事が理由で発生するため、今後予定されている、メニューUIの完全独自化にて対応できるか検討する予定です。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 返信 13 14:38
「非アクティブで復帰する」、うまく機能しています!
かなりお手数をおかけしましたが、対応ありがとうございます!

>・「アイコンクリックでアクティブにしない」でのメニュー動作
> この設定がオンの場合、タスクトレイアイコンからメニューを開いて、メニュー以外をクリックしても、メニューは閉じられません。
確かに1つ前のテストビルドでも「マウスオーバー非表示」の設定に関係なく発生し、「アイコンクリックでアクティブにしない」に関連して発生していました。私が何か勘違いしていたようです。訂正ありがとうございます。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 返信 13 14:53
そういえば、「最前面表示」「最背面表示」をOFF、「アイコンクリックでアクティブにしない」「マウスオーバー非表示」をONの状態でタスクトレイアイコンの右クリックメニューから「マウスオーバー非表示」をOFFにすると、別のウィンドウによってthilmeraが隠されていてもthilmeraが前面に出てくる挙動がありますが、これは仕様ですか?

私としては、他のウィンドウをクリックすればthilmeraは再び隠れるので不便していませんし、どうしても嫌なら「ウィンドウ最背面」で防げますし、むしろマウスオーバー非表示ではなくウィンドウで隠れている場合にもユーザーが混乱しないいい仕様だと思っていました。

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 返信 13 14:57
すみません、追加の検証によると、上記の挙動はマウスオーバー非表示にしながらでのみ発生しました。

Gakuto Matsumura - Developer 返信 13 16:01
>「マウスオーバー非表示」をOFFにすると、別のウィンドウによってthilmeraが隠されていてもthilmeraが前面に出てくる挙動がありますが、これは仕様ですか?

こちら、ここの11日分によりり変更された以下の仕様ですが、そうではないということでしょうか?
これは冒頭の不具合報告により修正したものになります。

 ● マウスオーバー非表示の設定を、非表示状態でオフに切り替えるとウィンドウが戻ってこない問題で、オフ時にウィンドウ表示をリセットして表示するように変更

elphe - 2235@1PwZwX1/PPZ/PPG2ufPG/G2m2t0PGg0 返信 13 22:01
> ● マウスオーバー非表示の設定を、非表示状態でオフに切り替えるとウィンドウが戻ってこない問題で、オフ時にウィンドウ表示をリセットして表示するように変更
質問が分かりづらかったですね。この「ウィンドウ表示をリセットして表示する」というのは、thilmeraと他のウィンドウとの元々の前面/背面の関係を無視して最前面に表示するという意図を含むのかどうか、という質問だとお考えください。

例えば、元々thilmeraが他のどのウィンドウよりも前面に配置されていた状態で「マウスオーバー非表示」をOFFにした際にthilmeraが最前面に表示されるのは理解できます。

今問題にしているのは、thilmeraをThunderbirdの背面に配置した状態で「マウスオーバー非表示」をOFFにした際に、元々Thunderbirdに隠れていたthilmeraがThunderbirdの前面に表示され、thilmeraがThunderbirdの一部を隠すようになる挙動です。

前述の通りこれはいい仕様であるとも考えていますが、「マウスオーバー非表示」をOFFにしてもthilmeraと他のウィンドウとの前面/背面の関係が変わらないというのが直感的に期待される動作だとも思えますので質問させていただきました。

Gakuto Matsumura - Developer 返信 13 22:07
>この「ウィンドウ表示をリセットして表示する」というのは、thilmeraと他のウィンドウとの元々の前面/背面の関係を無視して最前面に表示するという意図を含む

意図した動作はこれの通りになります。

>「マウスオーバー非表示」をOFFにしてもthilmeraと他のウィンドウとの前面/背面の関係が変わらないというのが直感的に期待される動作

そもそも、マウスオーバー非表示は、使用中にオンオフするようなものではない。という前提で作成していますが、どのようなものを想定されていますか?

私の立場からすると、手動によりオフにしたのに、ウィンドウが見えない。戻ってこない。という事態になるほうがまずいと認識しています。

ただし、これの前提には、マウスオーバー非表示という属性の変更は、頻繁にするものではなく、メインメニューにこれがあるのは、復元方法がない(方法が難解)という意見が過去に多数あったからで、頻繁に行うためにメインメニューに入れているわけではないです。
復元しにくいという過去の意見がなければ、そもそもメインメニューには置くことが無かった項目になります。

Gakuto Matsumura - Developer 返信 13 22:16
メインメニューにおける「マウスオーバー非表示」は、緊急時の復旧用。という想定なので、もしマウスオーバー非表示にまつわる挙動の一部のオンオフをコントロールしたい。という場合は、それは別の機能として具体的にどういう動作にしたいかを、要件を元に検討していく必要があります。

つまり、マウスオーバー非表示のオンオフは、緊急時の強制リセットボタン。という立ち位置で、操作中にオンオフするならば、対象は最も根本にあたるその部分ではない。ということになります。

elphe - 2235@1PwZwX1/PPZ/PPG21f1m2f2mJ/0P1G2 返信 14 10:25
意図された動作だったのですね。理解しました。

>>「マウスオーバー非表示」をOFFにしてもthilmeraと他のウィンドウとの前面/背面の関係が変わらないというのが直感的に期待される動作
>
>そもそも、マウスオーバー非表示は、使用中にオンオフするようなものではない。という前提で作成していますが、どのようなものを想定されていますか?
私が想定していたのは、「マウスオーバー非表示」「右下固定」がONで、うっかり「アイコンクリックでアクティブにしない」をON、「ウィンドウ最前面」をOFFにした状態で意図的にthilmeraを最前面に引きずり出す際に、マウスを右下領域から離さないと「ウィンドウ最前面」をONにしても表示されないと予見して一時的に「マウスオーバー非表示」をOFFにしたら、まだ「ウィンドウ最前面」をONにしてないのに最前面に表示されたとなると少し驚くだろうな、という程度でした。

>私の立場からすると、手動によりオフにしたのに、ウィンドウが見えない。戻ってこない。という事態になるほうがまずいと認識しています。
おっしゃるとおりで、もしそれが仕様、つまり開発者様の意図された挙動であるならば良い仕様だ、というつもりで質問しました。(この辺りも言葉足らずでしたね。すみませんでした。)

私の立場からはたとえ自然言語で記述されていても開発者様の意図を正確に汲み取ることはできず、thilmera自体も開発者様の意図に沿った挙動とそうでない挙動が混じっている現状です。(thilmeraに限らず、ソフトウェア全般に言えることですが)
たとえ良い挙動だとしても、それは開発者様の意図が反映されたからかどうかは(私にとっては)別の話です。挙動に害がなくても、開発者様の意図に沿わない挙動なのであれば報告の必要があると思い、どちらかわからなかったので質問という形を取りました。

>ただし、これの前提には、マウスオーバー非表示という属性の変更は、頻繁にするものではなく、メインメニューにこれがあるのは、復元方法がない(方法が難解)という意見が過去に多数あったからで、頻繁に行うためにメインメニューに入れているわけではないです。
>復元しにくいという過去の意見がなければ、そもそもメインメニューには置くことが無かった項目になります。
>メインメニューにおける「マウスオーバー非表示」は、緊急時の復旧用。という想定
そのような経緯があったのですね。丁寧な回答ありがとうございます。

Gakuto Matsumura - Developer 返信 14 13:45
詳細ありがとうございます。

ウィンドウには、「ウィンドウ最前面」「ウィンドウ最背面」「ノーマル」の3種類があり、今回の話の場合は、この「ノーマル」に該当します。
3種類は全く別枠という扱いなので、ノーマルの範囲内で前面にきたとしても、「ウィンドウ最前面」属性のウィンドウより前にくることはありません。

あくまで、ノーマル属性のウィンドウの中で、アクティブになる(手前にくる)という内容なので、ウィンドウ最前面にしていないのにウィンドウ最前面に切り替わってしまうというわけではないです。

>マウスを右下領域から離さないと「ウィンドウ最前面」をONにしても表示されない
「ウィンドウ最前面」の場合、他のウィンドウより後ろになって見えないという状態にはなならないので、ウィンドウ最前面にした場合、マウスオーバー非表示を解除しないと出てこないようなケースは考えにくいです。

質問や不具合報告や修正依頼で、最終的にソフトウェアの修正にならない場合でも、元となった疑問等は、ヘルプに記載する案内の内容に何が必要で、何が不足しているのかの参考になるので、とても助かります。

elphe - 2235@1PwZwX1/PPZ/PPG21lfflGPu2X/w1JwJ 返信 14 14:47
>あくまで、ノーマル属性のウィンドウの中で、アクティブになる(手前にくる)という内容なので、ウィンドウ最前面にしていないのにウィンドウ最前面に切り替わってしまうというわけではないです。
そこまで考慮していませんでした。ありがとうございます。

>>マウスを右下領域から離さないと「ウィンドウ最前面」をONにしても表示されない
>「ウィンドウ最前面」の場合、他のウィンドウより後ろになって見えないという状態にはなならないので、ウィンドウ最前面にした場合、マウスオーバー非表示を解除しないと出てこないようなケースは考えにくいです。
イメージとしては、
新規ユーザー「右クリックメニューから「ウィンドウ最前面」をONにした際にマウスカーソルがthilmeraにかかったままなので「マウスオーバー非表示」により表示されないままだろう。それはちょっと面倒なので、先に「マウスオーバー非表示」をOFFにしてから「ウィンドウ最前面」をONにしよう」

「マウスオーバー非表示」をOFFにしたタイミングでthilmeraが前に現れる

新規ユーザー、いささか動揺
という想定でした。
行動原理も「面倒」だったり結果も「少し驚くだけ」のかなり些細な話で、「ウィンドウが現れない」みたいな不具合の話でもなく、質問には答えるけどだいぶしょうもない話なので無視してよい、という意図で書いていました。色々紛らわしくてすみません。

Gakuto Matsumura - Developer 返信 14 22:10
それぞれ
・「ウィンドウ最前面」は、最前面属性への切り替え。
・ マウスオーバー非表示によるリセットは、各属性の範囲内でウィンドウをアクティブにする。

という、動作としては全く別の物なので、むしろ前の話の意図としては、他の後ろにあるウィンドウを前面に移動させる。という意図での「ウィンドウをアクティブにする」というメニュー項目がないのが一番の問題であるように思いました。

日本語の文面の意味としての「最前面」や「前面」という語句が、システム上の区分けの話なのか、見た目のウィンドウ位置が前か後ろなのか、のどちらの意味かによって、ユーザーが困惑するというのは確かにそうかと思います。

厳密な定義はちょっと記憶が曖昧ですが、元々は"TOPMOST"というWindows上の属性を、そのまんま日本語で書いたら最前面かなぁ。と書いたのが元なので、その時点から既に間違えているような気がしなくもない…です。

AIに投げてみると、「最前面に表示されるウィンドウ」あるいは「常に前に表示されるウィンドウ」と表現することが適切、と返ってきました。

ただ、設定の中には「常時」という、OSに備わっていないプロダクト固有の無理矢理な設定項目があるので余計ややこしいのですが、この項目があるがために、ウィンドウ最前面という設定そのものが、まるで毎回最前面にする機能。と誤認されるケースを生んでいる原因の一つのような気はします。

おそらく要点は、「ウィンドウをアクティブにする」というものが、「ウィンドウ最前面」とは別に、同時にメニュー内にはっきり存在している事だと思ったので、このあたりを整理し、ひとまずch0に次回更新予定のプレビューとして更新しました。

メインメニューに関係した変更内容は以下となります。

 ○ メインメニュー
  ・マウスオーバー非表示などの、緊急用の項目をサブツリーに移動
  ・「ウィンドウをアクティブにする」というシングルアクションを追加

elphe - 2235@1PwZwX1/PPZ/PPG2gGPg1gXtZtt2tuwZ 返信 15 19:39
>それぞれ
>・「ウィンドウ最前面」は、最前面属性への切り替え。
>・ マウスオーバー非表示によるリセットは、各属性の範囲内でウィンドウをアクティブにする。
>
>という、動作としては全く別の物なので、むしろ前の話の意図としては、他の後ろにあるウィンドウを前面に移動させる。という意図での「ウィンドウをアクティブにする」というメニュー項目がないのが一番の問題であるように思いました。

>おそらく要点は、「ウィンドウをアクティブにする」というものが、「ウィンドウ最前面」とは別に、同時にメニュー内にはっきり存在している事だと思ったので、このあたりを整理し、ひとまずch0に次回更新予定のプレビューとして更新しました。
良い機能ですね!まさか対応していただけると思っておらず、感激しました……!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 起動時の重要なお知らせがメインディスプレイに表示されない
#1023
uhokun - 2250@JPwZ200t0f2Z120fG/tuw/X20 返信 2024/02/13 23:18
デュアルモニタでディスプレイ2をメインディスプレイにしているが、起動時の重要なお知らせ画面が必ずディスプレイ1側に表示される。
重要なお知らせ画面をメインディスプレイ側に移動後閉じて再起動しても再度ディスプレイ1側に表示されます。

添付画像左がディスプレイ1(サブ)、右が2(メイン)です。

Gakuto Matsumura - Developer 返信 14 00:08
ありがとうございます。

言われてみれば、たしかにその通りですね!

元よりメインモニター(プライマリ)かどうかではなく、モニターに由来する内容の先が特定されていない場合、必ず0番(0番は必ず存在するため)を固定して使用するという仕組みになっていました。

モニターの列挙と記録の内容を整理し、メインモニターのフラグを発見した場合はそのモニター。一切プライマリのフラグが通知されない場合を除き、OSにてメインモニターと指定されているモニターを標準的に利用する。という変更をしました。

以下にて確認して頂けると助かります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240214-000441.zip

uhokun - 2250@JPwZ200t0f2XtP0Jg22tgX1/lZg 返信 14 22:06
早速のご対応ありがとうございます!

メインディスプレイに設定されている側に重要なお知らせ画面が表示されることが確認できました。

Gakuto Matsumura - Developer 返信 14 22:11
ありがとうございます。

ch0に、更新前のプレビュー版として、適用バージョンを出しておきました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 GPUのファンが表示されない
#1016
キャシー - 2245@uPwZ22Pt/wPPlGP10XgZwmt1/flwlm 返信 2024/02/05 08:42
GPUのファン情報が表示されません。

Gakuto Matsumura - Developer 返信 05 12:22
報告ありがとうございます。

こちら、設定やOSのバージョン。GPUの種類は何であるか。そのライブラリやドライバの設置状態はどうなっているか。低負荷によりファンレス状態になっていないか。などが、どれに該当するのかの情報がまず必要です。

まずはレポートの「GPU情報」の中身のコピーと、"thilmera7.ini"をここに添付して下さい。

キャシー - 2245@uPwZ22Pt/wPPlG0fw0/2//0uuGJXP2 返信 06 08:40
本日、PCを起動したら表示されました。
ファンレス状態のために非表示になったと予想します。
アップデート前までは表示されていたので、アップデートの影響と勘違いしてしまいました。
お騒がせしました。

Gakuto Matsumura - Developer 返信 06 11:10
状況がよくわからないですが、プログラム開始時に、セミファンレスにおける回転0を無効であるとは判断しないようにしているはずなのですが、何分、4つの大本のルート毎、かつそれぞれのOSやハードの新旧と、その中でも種類で別れるため、確認できていないルートがあるかもしれません。

とりあえず、恐らく効果はないであろう場所の条件を変えてはみました。
可能ならば、そもそもNVIDIAなのかRadeonなのかIntel HDなのかIntel Arcなのか、それだけでも教えていただけると幸いです。

キャシー - 2245@uPwZ22Pt/wPPlGJ1GXtuXw2JwJJmtm 返信 07 09:00
GPUはIntel Arcです。thilmera起動時にGPUのファンが回転していないと、thilmeraはGPUのファン項目を表示しません。thilmera起動後にGPUのファンが回転しても、thilmeraのGPUのファン項目は非表示のままです。
それから、レポートの「GPU情報」と"thilmera7.ini"を添付します。レポートの「GPU情報」は、ファン項目が表示されている場合とされていない場合の2種類を用意しました。なお、ファン項目がない「GPU情報」は、thilmera起動時、GPUのファンは回転していませんでしたが、レポート取得時には回転していました。

[appended] zip

Gakuto Matsumura - Developer 返信 07 12:40
具体的な内容ありがとうございます。

Intel Arcはまだ動作確認した環境は、希望者と後の私の2つ分のみ。となっています。

GPU情報を見た限り、今までにないパターン(表示されるものされないもの)になっているので、まずは以下にて、現行バージョンでログを出すモードのテストビルドを作成したので、こちらを実行して出力される、"debug_log.GPU.txt"を頂けると助かります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240207-123355.zip

キャシー - 2245@uPwZ22Pt/wPPlGwuXf22Xw//ZmX//G 返信 07 15:16
テストビルドの実行準備はできましたが、GPUのファンはPC起動時以外、ほとんど停止しません。GPUファンの非表示を再現したときのログを送りたいので、しばらくお時間を頂きます。

キャシー - 2245@uPwZ22Pt/wPPlG00G2Z1uXG20g/fm 返信 09 08:48
"debug_log.GPU.txt"を送付いたします。なお、本日の状況は次のとおりです。
PC起動後の自動実行では、回転数「0RPM」が表示されました。
thilmeraを終了して、手動実行したら、今度は表示されませんでした。
もう一度、thilmeraを終了して、再実行したら、その間にファンの回転が始まり、thilmeraは回転数を表示しました。

[appended] zip

Gakuto Matsumura - Developer 返信 09 15:55
ありがとうございます。
ログを見る限り、項目のサポートフラグ(その項目のデータが存在するかの値)は、全期間を通して一律(そのハードウェアならば同一の結果)ではないのかもしれない、という前提で、初期化時の有効無効のログ出力の追加と、初期化時に有効ではない項目が後から有効とされている場合のログ出力と有効への切り替えを作ってみました。

以下でもう一度試してほしいです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240209-155255.zip

キャシー - 2245@uPwZ22Pt/wPPlG0/0Zwmul2fGmG0ll 返信 10 08:57
新しいテストビルドのログを添付します。なお、本日の状況は次のとおりです。
PC起動後の自動実行では、回転数「0RPM」が表示されました。
thilmeraを終了して、手動実行したら、今度は表示されませんでした。
そのまま放置したところファンの回転が始まり、前回のビルドでは非表示のままでした回転数はが、今回のビルドでは表示されました。

[appended] zip

Gakuto Matsumura - Developer 返信 10 21:48
ありがとうございます。

こちらの問題、根本的な原因は、Intel Arc関連の公式ライブラリが、そもそも無いと返している所にありますね。

今回実用上のフォロー自体(ライブラリがあると返した時点から有効に改めてシフトする)はできたと思うので、ひとまずch0にて、この補正ありのバージョンに更新しました。

キャシー - 2245@uPwZ22Pt/wPPlGfw1GJlZuwZ/lP1m/ 返信 13 08:35
ご対応、ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 「マウスオーバー非表示」がONでマウスオーバーしても非表示にならない
#1022
elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 返信 2024/02/12 01:21
短時間に何度もすみません。
#1021の(1つ目の)テストビルドでも同様の症状が見受けられました。以下が再現手順です。
1. 「ウィンドウ最前面」をOFFにしておく(右クリックメニューが隠れて見づらくなるのを防ぐため)
2. thilmeraの右クリックメニューから「最小化」を選択し、非表示にする。
3. タスクトレイからthilmeraの右クリックメニューを呼び出し、「マウスオーバー非表示」をONにする
4. 再度タスクトレイからthilmeraの右クリックメニューを呼び出し、「元のサイズに戻す」を選択してthilmeraを表示させる
5. こうなると、thilmeraはマウスオーバー非表示を受け付けない(不具合)
6. 「マウスオーバー非表示」をOFFにしたのち、普通に「マウスオーバー非表示」をONにするとマウスオーバー非表示を受け付けてくれるようになる

elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 返信 12 01:23
0b180 refresh D r22 DEV6でも確認できるので、修正の副作用ではないと思われます。

Gakuto Matsumura - Developer 返信 12 19:22
ありがとうございます。

以下にて変更の内容
・「アイコンクリックでアクティブにしない」の設定がある場合に、アクティブ化してしまうルートの調整(スクリーンショット関連でのハンドリングは現行のまま)
・「ウィンドウ位置リセット」「最小化」「元に戻す」などで、マウスオーバー非表示関連での一時フラグをリセット
・関連して見つけた、「アイコンクリックでアクティブにしない」設定で、「ウィンドウ位置リセット」をしても他のウィンドウの裏に隠れて見えない問題で、フォアグラウンド復帰を必ずコールするように変更

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240212-191803.zip

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 返信 12 20:11
こちらの不具合は解消を確認できました!

elphe - 2235@1PwZwX1/PPZ/PPG2u1GgXumXJ1lXwf0 返信 12 20:24
すみません、言葉足らずでした。

>・「ウィンドウ位置リセット」「最小化」「元に戻す」などで、マウスオーバー非表示関連での一時フラグをリセット
こちらの修正を確認でき、「マウスオーバー非表示」がONでマウスオーバーしても非表示にならない不具合の解消を確認できたという意味です。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 ウィンドウ位置が固定されない
#1020
elphe - 2235@1PwZwX1/PPZ/PPG2XmwmPtt/lt/1w0fu 返信 2024/02/11 12:13
設定>表示>ウィンドウ(以下略)の「サブ-ロック」「右下固定」「右上固定」「左下固定」が機能しません。
バージョンは0b180 refresh D r22 DEV6です。

P.S. どうでもいい追伸ですが、thilmeraのメインウィンドウをマウスでドラッグするとデコ++キューブの回転速度が目に見えて速くなっていました。

[appended] ini

Gakuto Matsumura - Developer 返信 11 13:50
報告ありがとうございます。
2点修正しましたがサブ-ロックに関して、もし指摘されている問題が、位置補正なしの状態でモニター間を手動でのドラッグで移動できる。という事ならば、それはそういうものなのでどうしようもないきがします。
もしそれを防ぐならば、サブ-ロックが位置補正と同様の効果を併せ持つ上位設定という新しいものにするしかないです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240211-134626.zip

 ● ウィンドウ位置
  ・サイズの変更を伴わないウィンドウ変更時に、描画内容の再生成をコールしないように変更
  ・右下固定などを再編成し、ウィンドウ変更のメイン処理に統合

elphe - 2235@1PwZwX1/PPZ/PPG2XmwmPtt/lt/1w0fu 返信 11 14:35
>2点修正しましたがサブ-ロックに関して、もし指摘されている問題が、位置補正なしの状態でモニター間を手動でのドラッグで移動できる。という事ならば、それはそういうものなのでどうしようもないきがします。
そうだったのですね。失礼しました。

テストビルドを試してみたのですが、「サブ-ロック」「右下固定」「右上固定」「左下固定」をすべてOFFにしたのち、「~固定」の項目をONにしてもすぐには反映されず、再度「サブ-ロック」「右下固定」「右上固定」「左下固定」のいずれかのON/OFFを切り替えるか無理矢理ドラッグしようとしたときに初めて反映される不具合があるようです。

elphe - 2235@1PwZwX1/PPZ/PPG2XmwmPtt/lt/1w0fu 返信 11 14:47
すみません。報告内容に一部誤りがありました。
>「サブ-ロック」「右下固定」「右上固定」「左下固定」をすべてOFFにしたのち、「~固定」の項目をONにしてもすぐには反映されず、再度「サブ-ロック」「右下固定」「右上固定」「左下固定」のいずれかのON/OFFを切り替えるか無理矢理ドラッグしようとしたときに初めて反映される不具合があるようです。
例えば「サブ-ロック」「右下固定」「右上固定」「左下固定」をすべてOFFにしたのち、「右上固定」の項目をONにしたあと、「左下固定」の項目をONにしたとき、反映されたのは「左下固定」の項目でした。
ただし、「右上固定」の項目をONにしたあと、「サブ-ロック」をONにすると「右上固定」が反映されます。

Gakuto Matsumura - Developer 返信 11 16:58
ありがとうございます。

最初に頂いたiniにて、手順の通りに再現されたので、原因を調べたところ、0b180系から細分化された、位置やサイズのそれぞれの更新があるかどうかを最小限でOSに伝達するためのフラグに影響する部分で、右下固定などの補正後に移動した分を、変更あるなしの判定に加えていなかったようです。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240211-165543.zip

こちら、このあたりを調整してみました。

elphe - 2235@1PwZwX1/PPZ/PPG2ZffGgulmmGPm/lt2 返信 11 18:40
不具合の解消を確認しました!ありがとうございます!

ただ、色々いじっていたらほかにも不具合が見つかりまして、それはテストビルド特有の不具合ではないようなので別のスレッドを立てます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 `縦幅最大` を有効にしていても高さが目一杯にならない
#1019
tksk - 2249@GPwZP2PwPZPPmX/f/tug/lXm1JZJf 返信 2024/02/08 13:38
お世話になっております。

0b180 refresh D r22 DEV2 で、縦幅最大を有効にしているにもかかわらず、背景の描画がディスプレイ垂直方向に延びず、内容に応じた高さになってしまっています。

ご確認いただけましたら幸いです。
よろしくお願いします。

[appended] ini

Gakuto Matsumura - Developer 返信 08 13:46
頂いたiniで確認してみましたが、正しく画面の高さ最大になっていました。

問題が発現する条件やタイミング等はありますか?
起動方法や再起動。どのような状態でも発生しますか?

Gakuto Matsumura - Developer 返信 08 13:49
あと、元々問題なかったバージョンがいくつかは覚えていますか?

Gakuto Matsumura - Developer 返信 09 00:51
とりあえずどういう時系列となっているのかが知りたいので、問題が発生している環境で、同様の設定を移した以下テストにて、問題発生を確認したのと同様の状況のログをとってほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240209-004922.zip

"debug_log.Monitor.txt"というのが出力されます。

tksk - 2249@GPwZP2PwPZPPmgmfJJXfflJl2utXf 返信 10 17:16
お返事が遅くなりました。
ありがとうございます。
しばらくテスト ビルドを動かしてみて、状況が再現しましたらログを送付します。

起動直後は縦幅いっぱいの状態で、ふとしたタイミングで報告の状態になるみたいではあるのですが、現状タイミングは把握できていません。
DisplayPort 切断やスタンバイからの復帰に伴うデスクトップ領域の変化が原因なのかなという気はしています。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 起動できなくなった
#1018
さすけ - 2243@JPwZttGf2GP2//gZXg2PXPflw 返信 2024/02/07 20:24
たびたびすみません、今日PCを起動した所、自動起動するはずのシルメラが起動しなくて、代わりに「Can't write config file !」のダイアログがでるようになりました。手動起動でも同様です。

Gakuto Matsumura - Developer 返信 07 21:02
まず、自動起動というのがサービスの自動起動の事か、と、設置場所はどこか。
OSのバージョン、対象のシルメラのバージョンなどの情報をください。

そのエラーは、単純に書き出す必要がある"thilmera7.ini"の書き出しが、リトライ回数を経ても一切できなかった。というエラーです。

さすけ - 2243@JPwZttGf21PftlPfZ02X2lX1J 返信 07 21:12
試しに再起動したら起動できました。お騒がせしました。ちなみに設定のUACスタートアップサービスをON、シルメラのファイルの場所はDドライブのマイドキュメント、OSはWIN11、D r22です。

Gakuto Matsumura - Developer 返信 07 21:27
うーん、マイドキュメントに書き出しができない理由は、大本に適切な権限が割り振られていないとか以外では、あまりずばりこれという原因は思い当たらないですね…

ただ、サービスから無理やり起動させる昔からの方式には、元々モダンなOSのポリシーに準拠していない。という問題があるので、サービス稼働の内部で適切なユーザーの権限が拾えなかったか、別で動いているユーザー権限を間違えて取った結果、別のユーザーとして異なるユーザーのマイドキュメントにアクセス権限がなかった。といったケースは十分考えられます。

サービスから起動させる方式はポリシーに準拠していない事から廃止予定で、タスクスケジューラへの登録方式へ移行を行う予定になっています。

もし、複数のユーザーでログオンしている。などに心当たりがあれば、上記のトラブルである可能性が高そうです。

さすけ - 2243@JPwZttGf21PftlPfZ02X2lX1J 返信 07 23:55
PCは個人用でいつも管理者でログオンしてます。長くシルメラ使ってますが初めて発生しました。たまたま?だったのかもしれません。また起きるようなら報告します。タスクスケジューラへの登録方式、期待してます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 要望 ネットワークI/O、通信量カウンタの表示単位について
#1017
TomSato - 2248@wPwZlXtmPX11PPZwl11glllwJuPlgfJf 返信 2024/02/06 00:13
ネットワークI/O、通信量カウンタを表示させて使っていますが、この表示はbps固定でしょうか? ネットワークI/OではbpsのチェックをOFFにするとバイト単位となりますが、通信量カウンタの方は変化しません。できれば通信量カウンタの方もバイト単位の表示としたいです。

Gakuto Matsumura - Developer 返信 06 00:32
なるほど。
たしかに合計値であるSUMの方はbpsに追随するようにしていましたが、0b180系からはbpsを表示時の計算として、中身そのものを8倍とはしなくなっていたため、通信量カウンタがバイト単位固定でbps表記に追随していませんでした。

以下にて確認をお願いしま。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240206-003031.zip

TomSato - 2248@wPwZlXtmPX11PPZwl11glllwJuPlgfJf 返信 06 00:46
早急の対処をありがとうございます。通信量カウンタも連動してバイト表示になりました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 CPU使用率などのゲージとシルメラの表示位置について
#1010
さすけ - 2243@JPwZttGf2gP0uGfZXll10gtf 返信 2024/01/24 18:54
1. 最近のアップデートからですが、CPU使用率などのゲージが、画像の通り文字とくっ付くようになってしまいました。

2. メインモニターを代えてからですが、モニターの電源入れたり全画面でゲーム起動したりすると、いつも右端に表示してるシルメラの位置が左に寄るときがあります。そうなると「マウスオーバーで非表示」ONでマウスオーバーしても非表示にならないときもあり、タスクバーのアイコンクリックで一回表示を消して再表示してマウスオーバーすると元の右端に戻ります。最初から位置が動かないようにしてほしいです。

Gakuto Matsumura - Developer 返信 01/24
1に関しては、3x5ドットフォント。かつ行間最小限の0にしてみましたが、再現できませんでした。
"thilmera7.ini"ファイルを添付して下さい。

2に関しては、その代えたメインモニターが、前はHDMIで、後がDPとかだと、そのままの設定でハードウェアの仕様上そうなっても不思議ではないですが、マウスオーバー非表示に反応しなかったり、元の右端、というのも、設定により端に固定するものなど、色々な設定や色々な条件があるので、まずはどういう状況であるかの情報がもう少し必要です。

Gakuto Matsumura - Developer 返信 01/24
1に関して、色々可能な範囲で確認してみたところ、確かにライン2やボトムでは文字との間に余白がなくなるケースがありましたが、ここを今から根本的に作り直すとなると、やっと収まりかけている今回のバージョンでは収拾不可能となるので、臨時で申し訳ないですが、以下テストにて、スタイルのデータバー種類を設定する場所の下に、「詳細」というのを追加しています。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240124-213253.zip

ここの数値で、ライン2とボトムの場合の余白を手動で指定できるようにしてあるので、これの調整で一時的に要件を満たせるかどうかを確認してほしいです。

2に関しては今の時点で提示されている情報では案内できないので、1の結果と合わせてよろしくお願いします。

さすけ - 2243@JPwZttGf20fPG0fwGg2P/P10G 返信 01/25
1はテストのファイル入れて解決しました。ありがとうございます。iniファイルを添付しました。

[appended] ini

さすけ - 2243@JPwZttGf20fPG0fwGg2P/P10G 返信 01/25
2ですが、今日PCを起動したときの位置が画像の通りです。本来は画面の右端に表示してます。上下の位置は変わってません。今回はマウスオーバーしても右端に戻りませんでした。モニターの接続は3つ使ってますが、メインとメイン左のモニター(前のメインモニター)がDisplayPort接続で、メイン上のモニター(更に前のメインモニター)がDVI接続のところをケーブルでDisplayPortに変換して繋げてます。

Gakuto Matsumura - Developer 返信 01/25
> 1.
ありがとうございます。

> 2.
こちら、報告をうけてから私の方でも色々と実験してみていますが、一つは画面の電源がもどった後に、HDMIだけが認識されて、DP接続を含む全てのモニターが復帰するのは、HDMIのみの時に、画面外に出て補正された後となる問題。

もう一つは、DPIの変更(100%、125%など)が、たとえば200%の場合、ウィンドウを200%した分の右端で補正され、本来のサイズに戻ったら、画面比率分だけ端からズレるる。という問題。

調整を試みているので、また改めて報告します。

Gakuto Matsumura - Developer 返信 01/25
ひとまず、問題のうちの一つである、画面のDPI比率変更時に、ウィンドウの本来の位置とサイズではなくなってしまう問題への修正を試みたものを作成しました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240125-203456.zip
こちらで解決するかの確認と、出力されるログの"debug_log.Monitor.txt"を下さい。

さすけ - 2243@JPwZttGf2mwfJPw//PPm//ttl 返信 01/25
お手数おかけします。とりあえずログを添付しておきます。解決報告については、移動するときとしないときがあって、どういう条件でなるのかも不明なので、3日くらい様子みてみます。

[appended] txt

さすけ - 2243@JPwZttGf2PmGtwm/mmmJ0u/Xu 返信 01/28
様子見ましたが、一回も位置がズレませんでした。DPIで間違いないと思います。情報少ない中、原因の特定と解決、ありがとうございました!

Gakuto Matsumura - Developer 返信 01/29
ありがとうございます。

これに関して、更にちょっと調整(DPI関係)をしたので、さすけさんの環境で、以下のテストでも安定しそうか、可能であれば確認をお願いしたいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240129-222231.zip

さすけ - 2243@JPwZttGf2101mGwgmZtGX0fZt 返信 01/30
わかりました。また3日くらい様子見てみます。

さすけ - 2243@JPwZttGf2g02ZfugwXgPmJGZ2 返信 01 22:23
再び様子見ましたが、タスクスケジューラで設定してる時間指定シャットダウン後の起動で、また左にズレました。マウスオーバーで非表示にはなりましたが、元の位置には戻りませんでした。ただ、発生したのはその一回だけで、他の日のタスクスケジューラのシャットダウンや、手動でのタスクスケジューラ実行、手動のシャットダウン、再起動、全画面ゲームなどでは起きませんでした。

Gakuto Matsumura - Developer 返信 01 22:47
どちらかといえば、前回の直ったと思われた際には、再現がされなかったような気がしますね。

この問題には二つあり、一つはDPI変更によるもの。
もう一つはモニターの一部のみが復帰し、画面として存在しないために補正された結果、の二パターンです。

前者の修正は恐らく問題なさそう。
後者は、もし補正ありのままでやるならば、元々あったモニターが存在しない場合に暫定位置として、元々の第二位置が可能になったら移動する。みたいな機構がいりそうな気がします。

現行でもしこの後者が原因であった場合、

① サブロックをオンにする
② ①でだめな場合にさらに位置補正をオフにする

のどれかの段階でなんとかなりそうではありますが。

さすけ - 2243@JPwZttGf2g02ZfugwXgPmJGZ2 返信 01 23:58
①②はシルメラのウインドウ設定でよろしいでしょうか。とりあえずその2つの設定やってみました。また様子みてみます。

さすけ - 2243@JPwZttGf2GG1m/PXG0t0uuwZ/ 返信 05 18:36
設定変更で様子見ましたが、また起きるかもしれませんが、とりあえず一回も発生しませんでした。ただ、最初の修正ファイル適用以後は、ズレが激減したのは間違いないです。ゲーム起動の場合はほぼ毎回ズレてたのが全く起きなくなりましたし、他の場合も報告した一回だけです。

Gakuto Matsumura - Developer 返信 05 18:40
ありがとうございます。

とりあえず、現行正式リリースの最新、refresh D r22では、別件でモニター内部の位置が移動した際の相対位置を、内部で記録している絶対位置でそのまま上書きしてしまう昔ながらの問題にも対処したので、正式リリース版にて長期的にテストし、また発生したら知らせていただければと思います。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 WIndows11のディスプレイ設定変更時のウィンド消失
#1015
retsam - 2246@uPwZP1ZPwwGPP01mww0tgl2/Plw1202 返信 2024/02/02 22:14
2台以上のディスプレイを使用時に、Thilmera7を起動状態で表示しているディスプレイの位置関係をディスプレイ設定から変更すると、Thilmera7の表示が消失する場合があります。
この状態になると、再起動を実施しても表示が復活しません。可能であれば改善対応をお願いします。

Gakuto Matsumura - Developer 返信 02 22:18
こちら、現在修正の試験をしているch0の方でしょうか?

もし正式リリース側のch1(何も設定していない場合はこちらです)である場合は、ch0にて修正されているかの確認をお願いします。

ch0の現行である、C r21 DEV8でも以前として問題が修正されていない場合は、まず "thilmera7.ini" をここに添付した後、こちらで再現できなければテストを作成していきます。

retsam - 2247@uPwZP1ZPwwGPP010g2G2ul1fm12JJtl 返信 02 22:33
C r21 DEV8でも発生します。添付のiniはメインモニタの左側に設置したモニタにThilmeraを表示した状態で、メインモニタの右側に移動した場合のものです
ちなみに、位置関係を元に戻すと表示も復活します

[appended] ini

Gakuto Matsumura - Developer 返信 02 22:39
こちら、設定の位置補正がオフの場合、画面外にでた場合の補正は行われず、画面外であっても同じ位置をキープします。

そういう用途である設定なので、逆にこの設定のまま画面を移動しても内に収まるようにするのは難しいですが、どのような挙動がほしいですか?

位置補正をオンにすれば、存在する画面内のどこかに必ず収まるようになります。
マルチモニターで、かつ同じモニターに常に映し、画面内にも収まるようにするならば、
「位置補正」オン+「サブ-ロック」オン

常にどれかの画面内に表示したい場合は
「位置補正」オン+「サブ-ロック」オフ

どのような状態になろうとも、指定位置を変更せず、再起動してもそのままの位置を維持する場合は
「位置補正」オフ

となります。設定上はこの最後の状態になります。

また、画面外にでてしまったが、設定はそのままに画面内に戻したい。という場合は、右クリックなどからメインメニューを出し、「ウィンドウ位置リセット」「メイン」で回復します。

retsam - 2247@uPwZP1ZPwwGPP010g2G2ul1fm12JJtl 返信 02 23:02
個人的な要望としては、Thilmeraをサブディスプレイへ表示させているときに、論理的なディスプレイの配置をどのように変更しても、物理的なサブディスプレイ内では常に同じ位置で表示していてほしいです

retsam - 2246@uPwZP1ZPwwGPP01mww0tgl2/Plw1202 返信 02 23:09
ちなみにサブロックをONにすると、サブディスプレイに表示されていたThilmeraがメインディスプレイ側に移動し、サブ側に移せなくなるのですが、サブ側には留めておけないのですか?

Gakuto Matsumura - Developer 返信 02 23:14
頂いた設定をこちらで稼働してみたところ、「サブ-ロック」は元々オンの状態であったので、これは「サブ-ロック」のオンではなく、「位置補正」をオンにしたら。という内容であっていますか?

この流れから推察するに、サブロックと画面補正をオンにした際、画面内にないため、デフォルトであるメイン画面に移動した。と推察されます。

Gakuto Matsumura - Developer 返信 02 23:15
ウィンドウの各モニター上の相対位置は、新たにそれ専用の数値の記録と再現が必要となり、かなり根本にかかわる変更になるので少し怖いですが、設定分岐をオンにしないかぎり影響しない形で作れないか試してみます。

Gakuto Matsumura - Developer 返信 03 01:24
こちら、心当たりのある箇所が、ch1の状態ではまだ適用されていない部分が絡んでいることが確認できたのですが、問題発生はch1の正式リリースされているものでも発現していましたか?

ch0あるいはフォーラムにあるテスト版での発現でしょうか?
どちらでも起こるのかどうかが分かるとありがたいです。

retsam - 2246@uPwZP1ZPwwGPP01mww0tgl2/Plw1202 返信 03 11:21
ch1から発生しています。C r21 DEV8にしても挙動としては変わらないです

Gakuto Matsumura - Developer 返信 03 14:36
なるほど。
ということは大本であるOSの挙動に対する根本的な問題ですね。

その方向で確認してみると、DPI制御を自分で全てやる。という宣言をしても、DPIやモニターに影響された後に補正する、みたいな事しかできないようなので、以下はひとまず自分なりにこれならいけるかなぁと納得できる状態にしたものです。

確認と調整した内容は、
・モニターのDPIをOSから変更した時に、位置とサイズが保たれる(一瞬変わるのは防げないけど、元に戻す)事
・モニターの位置をOSから変更した時に、絶対位置を上書きしない

【補足】OSからウィンドウの位置移動がコールされた時に、本来のウィンドウサイズと異なる場合に無視し、サイズ変更のコール時に本来のサイズに再補正する

といった内容になります。
こちら、恐らく全てのユーザーで解決するかは、その人の環境によりそうですが、まずretsamさんの環境で解決するかどうかの確認をお願いします。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240203-143144.zip

Gakuto Matsumura - Developer 返信 03 15:27
以下追加修正。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240203-152310.zip

位置補正がオンの場合に、ユーザー操作以外で移動となった場合に一時的に補正しないフラグの追加。
大きく画面を移動した場合、モニターが変更されたという情報よりも先に、ウィンドウの位置がOSにより移動されたタイミングでは、古い位置情報での補正になってしまうため。

retsam - 2247@uPwZP1ZPwwGPP01wfX2lZflt//GXtww 返信 03 19:51
ありがとうございます。バッチリです!
添付のiniの設定ですが、ディスプレイの位置関係を変更しても表示位置は保持されています。
正式版に適用されるのを待っています。

[appended] ini

Gakuto Matsumura - Developer 返信 03 20:58
ありがとうございます。

とりあえずch0を更新しました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 論理ドライブ表示の設定が保存されない
#1014
キャシー - 2245@uPwZ22Pt/wPPlGgJPf2wtgPgX1ltJ1 返信 2024/01/31 15:15
設定の[ドライブ][論理ドライブ表示]にある「CD、DVDドライブ」と「リモートドライブ」ですが、チェックを外すと画面には反映されるのですが、設定が保存されないのか、PCを再起動するとチェックがついた状態になってしまいます。

Gakuto Matsumura - Developer 返信 01/31
本当だ…

報告ありがとうございます。
修正をch0にて更新しています。
ch0もしくは以下から確認して頂けると助かります。

以下は現行のch0と同様。
C r21 DEV8
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240131-184407.zip

キャシー - 2245@uPwZ22Pt/wPPlGPJXmZPmmZPJtGZfm 返信 02 09:25
ch0で「CD、DVDドライブ」と「リモートドライブ」のチェックが外れた状態で起動していることを確認いたしました。
迅速なご対応ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 PC起動時にウィンドウ最前面が維持されない
#1012
ナセル=フェレロ - 2130@t3z6EJ/S 返信 2024/01/26 23:23
0b180の、どの段階からかは気づけませんでしたが、PCを起動すると「ウィンドウ最前面」設定がONにもかかわらず、各種ウィンドウの背面にThilmeraが隠れてしまうようになりました。(*1)(*2)
以前は「ウィンドウ最前面ON」「常時OFF」の状態でPCを起動しても最前面が維持されていたのですが、現状ではクリーンインストールしても改善できず、やむなく「常時」をONにしています。

現在の設定ファイルの添付と、下記に環境や確認した操作を記します。

◆現象が確認できている環境
OS:Windows10 Home 64bit(intelプロセッサ)、Windows11 Pro Arm版(Parallels desktop for MAC)(*3)
ウィンドウ最前面設定:ウィンドウ最前面のみON、常時はOFF

◆確認作業を行った操作
・「シャットダウン」後に起動
Shiftを押さない通常のシャットダウン後、時間をおく・置かないにかかわらず、起動すると発生。

・Shift+「シャットダウン」後に起動
Shiftを押したシャットダウン後、時間をおく・置かないにかかわらず、起動すると発生。

・「再起動」
シャットダウンメニューの再起動を選択して再起動しても発生。

◆提出する設定ファイル
Windows10で使用しているThilmeraの設定ファイルです。

*1: ウィンドウ最前面を一度OFFにして、再度ONにすることで、次のシャットダウンまでは元に戻ります。
*2: ランダムですがマウスオーバー非表示ONの状態でマウスオーバー・アウト後に前面に一時的に登場、アイコンクリックによる格納・再表示で前面に一時的に登場しますが、作業ウィンドウでのクリックなどで、すぐ裏に隠れます。
*3: 仮想環境のWindows 11は原則サポート外と存じますが、参考情報として提出します。

[appended] ini

Gakuto Matsumura - Developer 返信 01/27

ナセル=フェレロ - 2130@t3z6EJ/S 返信 01/28
修正試験版ありがとうございます。
早速、使用中のThilmeraの自動起動を解除・ファイルを圧縮削除して、試験版のみが有効な状態で検証してみましたので、下記の通り報告いたします。

◆検証したPC
・Windows10 Home 64bit(intelプロセッサ)のみ

◆確認作業を行った操作
・「シャットダウン」後に起動
引き続き、PC起動後にブラウザなどを立ち上げると、Thilmeraは後ろに隠れます。

・Shift+「シャットダウン」後に起動
引き続き、PC起動後にブラウザなどを立ち上げると、Thilmeraは後ろに隠れます。

・「再起動」
引き続き、PC起動後にブラウザなどを立ち上げると、Thilmeraは後ろに隠れます。


上記の通り、どの操作方法を用いても改善されませんでした。
念のため、試験した際の試験版設定ファイル、試験版Thilmeraのレポート機能で出力したシステム・CPU・GPIのレポートを添付いたします。
修正のお役に立てば幸いです。

[appended] zip

Gakuto Matsumura - Developer 返信 01/28
なんでだろう…
今回のテストビルド前は明らかに再現できたのですが、こちらでは再現できませんでした。

左上に小さいTの文字があるかどうかは確認できますか?

ナセル=フェレロ - 2130@t3z6EJ/S 返信 01/28
タイトルバーとメインエリアの間に"T"と"G"が縦書きで表示されています。
スクリーンショットをとりました。添付しますので、ご確認ください。

Gakuto Matsumura - Developer 返信 01/29
こちら、仮想のwin10でサービス自動起動で起動すると再現ができました。

一応、確認した再現状態ではfixできましたが、直るかどうかはわかりません。
以下にて実際に確認をお願いします。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240129-222231.zip

ナセル=フェレロ - 2130@t3z6EJ/S 返信 01/30
再修正データありがとうございます。
早速Windows10環境で、再度試試験版のみが有効な状態で検証してみましたので、下記の通り報告いたします。

◆検証したPC
・Windows10 Home 64bit(intelプロセッサ)のみ

◆確認作業を行った操作
・「シャットダウン」後に起動
PC起動後にブラウザなどを立ち上げると、Thilmeraは手前にある状態が維持されました。

・Shift+「シャットダウン」後に起動
PC起動後にブラウザなどを立ち上げると、Thilmeraは手前にある状態が維持されました。

・「再起動」
PC起動後にブラウザなどを立ち上げると、Thilmeraは手前にある状態が維持されました。

上記の通り、検証したすべての手順において、問題は解消していました。
ご対応いただき、ありがとうございました。

Gakuto Matsumura - Developer 返信 01/30
ありがとうございます。

ch0にてテスト先行を出したので、こちらでとくに問題が報告されなければ、正式リリースとして更新予定です。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 Win7でGPU情報をうまく取得できない
#1009
bnmr - 2218@uPwZZ1Z2gwwPP/GuX2/tXgtGPGgmmG/ 返信 2024/01/23 01:24
0b180 r18からr21に更新したところ、VRAMが表示されなくなり、GPUレポートではGPUが2台多く表示されます。

Gakuto Matsumura - Developer 返信 01/23
どこがどうなっているのか予想がつかないので、以下にてログ"debug_log.GPU.txt"を取得してほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240123-013924.zip

bnmr - 2218@uPwZZ1Z2gwwPP/GuX2/tXgtGPGgmmG/ 返信 01/23
log

[appended] txt

Gakuto Matsumura - Developer 返信 01/23
あれ、スクリーンショットの内容と一致しない…

Gakuto Matsumura - Developer 返信 01/23
スクリーンショットではVramは表示されているようです。
GPUがダミーとなっているのはレガシー用のダミーなので正常ではあります。

Gakuto Matsumura - Developer 返信 01/23
>GPUがダミーとなっているのはレガシー用のダミーなので正常ではあります。
GPUが2つずつとなっているのは、本体とそれぞれのレガシー用のダミーなので正常ではあります。

bnmr - 2218@uPwZZ1Z2gwwPP/G10f2gXJwf/2wZuJu 返信 01/23
バックアップに180r18が残っていたので同じ設定で起動してみました。
r18ではAMD側のVRAMが表示されましたが、r21ではnvidia側しか表示されません。

[appended] zip

Gakuto Matsumura - Developer 返信 01/23
なるほど…
どれが何のスクリーンショットなのかがよくわかりませんが、最初のスクリーンショットで見えているVram-NV2の方ではなく、DXGI由来のVRAMがrefresh以降にレガシー対応判定ルートに入るが、レガシーなハードではないwin7では出ていた…ということですね。

ただ、win7ではハンドルがとれず、マッチングのしようがない、ただ単にどれがどのGPUかかわらないVRAMが列挙されるだけ。というものだったはずなので、マッチングと、マッチングできないならダミーが前提。という状態から、このケースにも対処するにはどうすればいいのか少し考えます。

Gakuto Matsumura - Developer 返信 01/23
とりあえず以下でどう出るかを試してほしいです。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240123-123422.zip

やった内容としては、VRAMが出せるがOSが古いレガシーと、OSはともかくハードウェアが古いレガシーの2ケースを分離し、VRAMのみとれるケースでは、VRAMルート上では、本体の有効無効とは別に、VRAMとるのに必要なデータさえあれば取る。というものにしています。

ダミーは同じなので、恐らく0,1がVRAMとして出てくるスロット(どのGPUであるかは不明)で、2,3が互換性用のダミーとして作成されたGPU本体の管理上のスロットとなります。

Gakuto Matsumura - Developer 返信 01/23
debug_log.GPU.txtのログと、GPUレポートの中身を下さい。

Gakuto Matsumura - Developer 返信 01/23
もしかしたらDXGI由来とVramNVの両方でそうな気がしますが、まずは可能な限りの情報を出すことが先なので、ひとまず結果を見てどうするか考えます。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf12ww/gmGZu0w/tf 返信 01/24
log

[appended] zip

Gakuto Matsumura - Developer 返信 01/24
ありがとうございます。

すみません、こちらのログは、ちゃんと最初のスクリーンショットが取られた時の設定で取得されていますでしょうか?

ログ取得時に、VRAMの表示設定がオンになってるかを確認してほしいです。
もし、スクリーンショットと同じ設定でもこうなっている。ということならば、さらにログの箇所を増やします。

bnmr - 2218@uPwZZ1Z2gwwPP/Gf12ww/gmGZu0w/tf 返信 01/24
iniを移植して取得し直しました。
問題なく表示されています。

[appended] txt

Gakuto Matsumura - Developer 返信 01/25
ありがとうございます。

こちら、早々にch0に先行、そののちリリースチャネルと思っていましたが、先に別の問題報告の様子をみてからにします。

確認した内容の方は、だめだろうと思っていた部分が全て動作しているという、予想していた修正群が必要なくそのまま使えそうな、かなりいい内容でした。

別件でのモニターに関する問題がまとまれば更新作業を再開します。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 GPUグラフ、タコメーター
#1008
タスマニアの悪魔 - 2239@gziI3HF9 返信 2024/01/22 06:29
設定のGPU項目GPU情報の稼働率にチェックしないと、グラフ・タコメーターが反応しない。

Microsoft Windows 10 Pro 64 ビット 22H2 (10.0.19045) Dark IE/11 JS/11.0.16384 ja_jp 96 AMD Ryzen 7 3700X 8-Core Processor

レポート: GPU情報

--------

flag: DXGI1, DXGIp1


---- GPU:0 ----

Name: NVIDIA GeForce RTX 2070

[DXGI]
dVRAM: 254.7KiB / 7.83MiB
sVRAM: 20.94KiB / 7.96MiB
Memory Frequency: 7.00GHz / 7.00GHz
Temperature: 49.8'C
Max Memory Frequency(Over Clock): 7.00GHz
Temperature Warning: 81.0'C
Temperature Max: 89.0'C

[NVIDIA]
PCIe x1 MaxSpeed: 3.00Gbps (375.0MBps)
PCIe Bus Speed: no correct / Gen3x16
Memory Bus: 256 bit
TT Shutdown: 94.0'C
TMT Slowdown: 91.0'C
TMT GPU Max: 89.0'C
TT Min Acoustic: 65.0'C
TT Current Acoustic: 72.0'C
TT Max Acoustic: 88.0'C


Gakuto Matsumura - Developer 返信 01/22
こちら、バグではなく、意図してそうなっています。
稼働率は稼働率で、わざわざそのために取得しなければならないケースがあるので、負荷を抑えるために元から収集しない。データを作成しない。というものになるので、少なくとも設計上は正しく、とても正しい挙動です。

この意見としては、メインとなる行内の稼働率だけ非表示となり、タコメーターやグラフが有効の場合は稼働率のオンオフに関わらずに収集する。という仕様にしてほしいという感じでしょうか?

Gakuto Matsumura - Developer 返信 01/22
もし単純に挙動がバグのように感じる。ということならば、設定上の組み方を考えます。

メインとなる行をオフ。または行の稼働率のみオフにして、他は表示したい。ということならばそれはそれで作ります。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/22
おつかれさまです。
負荷を抑えるための仕様だったんですね。
ウインドウ幅を狭くしている場合に稼働率を表示すると消費電力Wが見切れることがあったので、グラフ・タコメーターで表示しようとしていました。
負荷が増えすぎるのも考え物ですし、現状のままで気にしないことにします。
返信ありがとうございました。

Gakuto Matsumura - Developer 返信 01/22
なるほど。

①ではなく②であることから改めて確認したところ、確かに稼働率の取得を行いはしますが、本体の行の稼働率表示だけ消したい。というのは普通にありえることだと思うので、以下で対応してみました。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240122-230914.zip

変更内容は、稼働率、グラフ、タコメーターのいずれかがオンの場合、稼働率の収集は行い、稼働率のオフは、メイン行への表示を消す効果。グラフとタコメーターが無い場合は今までと同様。としました。

稼働率はいらないから負荷を極限まで抑えたいというニーズの人が、グラフとタコメーターを使用する可能性はないと思うので、今後はこちらでいこうと思います。

他になにかしらのクリティカルな不具合がない場合、この変更はch0での次期バージョン開発に回し、デフォルトリリースはr21を採用する予定です。

タスマニアの悪魔 - 2239@IvwLh4xP 返信 01/23
おつかれさまです。
確認しました。思い通りの表示にできました。
ありがとうございます。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 [半透明ウィンドウ]の[ウィンドウの透明度]がリアルタイムに変更されない
#1006
ANACOSTIA - 2241@PPwZZ1Pw2g1wPPgt1wffZJJXGfGwm1f 返信 2024/01/21 15:56
Win10 22H2で0b180 refresh r19です。

設定画面から各種設定を弄る際、他の項目はリアルタイムに設定が反映されるのに対し、[半透明ウィンドウ]の[ウィンドウの透明度]を変更する際のみ、設定画面を閉じても反映されず、反映させるには[半透明ウィンドウ]を一度OFFにしてから再度ONにするか、若しくはthilmera自体を再起動するかしかないようです。
当方の環境がWin10だからかもしれませんが。
尚、[ハードウェアアクセラレーションを使用する]がONの時はリアルタイムに反映されます。

Gakuto Matsumura - Developer 返信 01/21
報告ありがとうございます。

こちら確認でき、適用される内容はオンオフされた瞬間に、その時の値が適用されて、数値の変更時は適用されない処理となっていました。
前回の値を保持し、数値が変更された場合も適用処理を行うようにしました。
ハードウェア描画では、そもそもレイヤードも半透明も不透明も全く同じ属性の状態で、単に描画する内容の調整のみでるあのに対して、ソフトウェア描画は、不透明、半透明、レイヤードはそれぞれ別個の処理となります。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240121-160640.zip

ANACOSTIA - 2241@PPwZZ1Pw2g1wPPgt0uufPJ0ZZwXmu1 返信 01/23
r21において、[ハードウェアアクセラレーションを使用する]がOFFの時でもリアルタイムに反映されることが確認できました。
ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 スタートメニューへフォルダが自動的に作成される件
#995
七海灯 - 2233@uPwZP2ZfZGPPt1JtGwGfJXtwf21w22 返信 2024/01/15 11:32
最近のアップデートで、スタートメニューへ「thilmera 7 (Portable)」のフォルダが自動的に作成されていました。
こちらは自動アップデートで強制的に作成されるようになったのでしょうか?
また、これを作成しないようにするオプションはないのでしょうか?
(アップデーター上で設定する?)

Gakuto Matsumura - Developer 返信 01/15
こちらは2か月ほど前の0b180系のリリース以前から全員が同一である話で、要望によるものでしたが、逆に作ってほしくないケースというのは確かに考慮していませんでした。

とりあえず、現行までに関してはどうしようもないですが、0b180のrev17から、それ次回以降へのアップデート時に、設定から以下のオプションを指示して、設定を継承した状態でアップデートを行えるように、本体とアップデーター双方を更新しました。

設定欄は、「設定」「アップデート設定」「オプション」以下となります。


本体: 0b180 Rev.17
アップデーター: 0.6.2023NS Rev.8

完全に新しい仕様であるため、下位互換はありません。

今のところは、本筋の動作に問題がないかの確認だけお願いします。

Gakuto Matsumura - Developer 返信 01/15

 ○ 更新時のアップデーターへのオプション指定機能を追加
  プログラム本体からのアップデート時に以下のフラグを付けて呼び出す仕様を作成。
  ・ショートカットを作成しないオプション
  ・全てのアーキテクチャを展開するオプション
  リソース破損による緊急アップデートでは適用されません。

七海灯 - 2233@uPwZP2ZfZGPPt1u1Pu1G1GZftZ2m/l 返信 01/22
返信遅れました。
ご対応頂き有難うございました。
問題ないことを確認しております。
以上、宜しくお願いします。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 version 0b180 refresh r20 にアップデート後GPUの温度表示異常
#1007
ちゃっぺ - 2242@ybP2sLta 返信 2024/01/21 22:40
いつもお世話になっております。
先ほど0b180 refresh r20へのアップデートをしたところ、GPUの温度表示が桁ズレなのか10倍されるようになってしまいましたのでご報告させていただきます。

Gakuto Matsumura - Developer 返信 01/21
報告ありがとうございます。

ライブラリ由来の温度が利用できない場合に採用されるDXGIの値に、元となる数値の異なる単位が混在している問題への補正で、確認してみたところ、確かにRadeonの表示にむける数値の桁だけ一桁多くなっていたようです。

更新したので確認をお願いします。

0b180 refresh C r21

ちゃっぺ - 2242@ybP2sLta 返信 01/21
早速の対応ありがとうございます!
0b180 refresh C r21
にて正常に戻ったのを確認しました。

ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 不具合 論理ドライブ表示周りの不具合(と思しきもの)
#1005
elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 2024/01/21 12:15
#998の者です。その節はありがとうございました。
こちらの環境でもversion 0b180 refresh r19では#998の不具合は解消されていることを確認できました。

ただ、version 0b180 refresh r19の論理ドライブ表示周りにて2点ほど気になる点がありました。
・「論理ドライブ」の下の設定で、マウントされたドライブの表示/非表示の設定が機能していないようです。例えば「ドライブリスト」から「D: 表示」のチェックボックスを外してもthilmera上では表示されたままです。
・スクリーンショットで、Cドライブは警告表示になっていますが、このとき棒グラフが(おそらく)表示されていないようです。警告表示になっていないDドライブやGドライブは文字の下に棒グラフが表示されていますが……

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
iniファイルはこちらです。

[appended] ini

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
追加情報です。
設定の「スタイル」から「左右反転」をONにしても、警告表示のCドライブは左右反転しないようです。

Gakuto Matsumura - Developer 返信 01/21
>「論理ドライブ」の下の設定で、マウントされたドライブの表示/非表示の設定が機能していないようです。例えば「ドライブリスト」から「D: 表示」のチェックボックスを外してもthilmera上では表示されたままです。
こちら、確認したところ、非表示に切り替えた時に、中途半端に更新だけ停止して古いデータの表示が残ることが確認されました。
再編成に由来するフラグの伝達ミスのようです。

>・スクリーンショットで、Cドライブは警告表示になっていますが、このとき棒グラフが(おそらく)表示されていないようです。警告表示になっていないDドライブやGドライブは文字の下に棒グラフが表示されていますが……
こちらは、白と赤のうち、赤がバーに相当します。
下にバー表示するスタイルだとバーが無いというのが不思議に感じるかもしれません。
元々のスタイルでは、反転色となり、本来の中身は赤(memory-modifiedカラー)と白(text-color)で表されます。
ただ、確認したところ、母数の単位が100分の1になっていました。

> 設定の「スタイル」から「左右反転」をONにしても、警告表示のCドライブは左右反転しないようです。
こちら確認してなかったのですが、どうも相当昔からこうだったようです。
とくに弄った記憶がない…

以下3点修正しました。
確認をお願いします。

repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240121-152129.zip

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
リンク先が「404 Not Found」になっていて何もダウンロードされません……

Gakuto Matsumura - Developer 返信 01/21
すみません、アップロードミスでした。
もう一度お願いします。

elphe - 2235@1PwZwX1/PPZ/PPG2PP1/GJ20glZwGu0 返信 01/21
修正を確認できました!
対応ありがとうございます!

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

[Closed] 報告 ディスクIO一覧が表示されない
#1002
タスマニアの悪魔 - 2239@gziI3HF9 返信 2024/01/19 06:54
1.ディスクIO一覧が表示されない
2.ディスクIOの%が常に100%になる
3.ロードキャッシュを含むをチェックしないとディスクIOの値が0
 thilmera.com/page-help-31の内容は実行してみました
4.設定の壁紙で論理ドライブ表示が点滅する タイトルバーをポイントしている間だけ正常に。
5.トッププロセス項目でオプションの降順にチェックしないとトッププロセスディスクIOの表示が空欄になる
6.メモリ項目でビデオメモリオン、DXGIオンにするとVRAMが表示されなくなる
 GPU情報エリアに表示をチェックすると情報エリアに表示されるようになる
Microsoft Windows 10 Pro 64 ビット 22H2 (10.0.19045) Dark IE/11 JS/11.0.16384 ja_jp 96 AMD Ryzen 7 3700X 8-Core Processor

[appended] ini

Gakuto Matsumura - Developer 返信 01/19
報告ありがとうございます。

> 1.ディスクIO一覧が表示されない
> 2.ディスクIOの%が常に100%になる
> 3.ロードキャッシュを含むをチェックしないとディスクIOの値が0
 thilmera.com/page-help-31の内容は実行してみました

こちら3つは、ディスクIOに関するものですね。
ディスクIOが常に100%で、ロードキャッシュを含むと0%(おそらく完全0ではないと思いますが)というのは、システムがRAID構成の再同期など、IOに換算されない処理をしている場合はありうるものではあります。

ただ、一覧が表示されないとなると本当に0なので、頂いた設定で確認してみましたが、正常な内容で再現はできませんでした。

常に100%となるという場所で、WriteとReadの値は0でしょうか。0以外でしょうか?


> 4.設定の壁紙で論理ドライブ表示が点滅する タイトルバーをポイントしている間だけ正常に。

こちら、#998, #999, #1001にて修正したものがあるので、下記のもので同時に確認をお願いします。

> 5.トッププロセス項目でオプションの降順にチェックしないとトッププロセスディスクIOの表示が空欄になる

こちら再現できたため、下記にて修正しています。

> 6.メモリ項目でビデオメモリオン、DXGIオンにするとVRAMが表示されなくなる
 GPU情報エリアに表示をチェックすると情報エリアに表示されるようになる

まず、対象のVRAMを搭載するGPUの種類や状態がわからないので、レポートのGPU情報を開き、内容をコピーして下さい。


4.と5.の件へのテスト版
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-132531.zip

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/19
おつかれさまです。

1.2.3.
ロードキャッシュを含む にチェックを入れるとWrite、Readともに2.36Mなど正常表示されます。
チェックを外すと完全に0になります、数分眺めていましたが、ピクリともしませんでした。 グラフにも反応はありませんでした。
%の場所は起動時から常に100%です。 スクリーンショットを添付します。
RAIDは組んでいません。

再現できなかったとのことで、こちらの環境の問題でしょう。 お手数おかけしました。


4.5.
テスト版にて修正を確認しました。


6.
レポート: GPU情報

--------

flag: DXGI 1, DXGIp 1


---- GPU:0 ----

Name: NVIDIA GeForce RTX 2070

[DXGI]
Memory Frequency: 7.00GHz / 7.00GHz
Temperature: 39.0'C
Max Memory Frequency(Over Clock): 7.00GHz
Temperature Warning: 81.0'C
Temperature Max: 89.0'C

[NVIDIA]
PCIe x1 MaxSpeed: 3.00Gbps (375.0MBps)
PCIe Bus Speed: no correct / Gen3x16
Memory Bus: 256 bit
TT Shutdown: 94.0'C
TMT Slowdown: 91.0'C
TMT GPU Max: 89.0'C
TT Min Acoustic: 65.0'C
TT Current Acoustic: 81.0'C
TT Max Acoustic: 88.0'C

レポート便利ですね!

Gakuto Matsumura - Developer 返信 01/19
> 1.2.3.
こちら、原因がよくわからないので、そもそも中身の数値としては何がとれているのかをざっくりですがログに出すものを作りました。下記のテストから、20秒程度走らせて出力される"debug.DISK_IO.txt"を添付して下さい。

> 4.5.
ありがとうございます。

> 6.
こちら、再現ができたので、いっそ再編成してみました。

変更はこのような感じになります。

 ● VRAMのルート再編成
  DXGIオン+ドッキングがオフの状態で、VRAMが表示されないケースへの修正として、VRAMのルートを再編成。
  VRAMにおけるDXGIオプションの仕様を変更し、レガシーを強制するスイッチではなく、DXGI由来とライブラリ由来のどちらを優先するかの設定に変更。
  以降は環境により表示可能なデータがあれば、可能な限り表示されるようになります。
  NVIDIAのライブラリからのVRAM取得は、レガシー用に重複して作成されることはなくなり、GPU情報で生成済みのものを参照する形に変更されています。


repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240119-221756.zip

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/20
1.2.3.
添付いたします。

6.
確認しました。
NVOとD-Vramて結構数値が違うんですね。

[appended] txt

Gakuto Matsumura - Developer 返信 01/20
> 1.2.3.
見事に何もないですね。
エラーすらでていない…

一つ追加で確認をお願いしたいのですが、「設定」「日時」「システム稼働時間」をオンにした場、内容は異様なものではなく、正しい時間がカウントされていっていますか?

利用側としては関係のない部分ですが、内部として参照元になるOSのシステムが破損している場合、この「システム稼働時間」の結果も明らかにおかしい、化けた時刻になるので、そこが正しい時間数でカウントされるかを確認してほしいです。


> 6.
DXGI由来とライブラリ由来は、こちらでも数パーセントの違いを確認していますが、グラフィックボード内部で予約されている容量のようなものが、込みとして出るか、省かれて出るかの違いのような気がします。
こちらの環境では、空き容量の値は同じでした。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/20
高速スタートアップがONになっていて1day 23:00とかになっていました...
それでも数日前にヘルプに書いてあったシフト+シャッドダウンしてたので、おそらく普通の値ですね。
タスクマネージャの稼働時間も同じ値で正常に見えます。

Gakuto Matsumura - Developer 返信 01/20
なるほど。
では、純粋に本来ならば取れてないとおかしい部分や、何がとれるかを全て列挙するテスト専用のものをさらに追加したものを作成しました。
repo.thilmera.com/pac/thilmera7/managed/test/thilmera7test_build_win64_20240120-232436.zip

こちらで再度ログの方をお願いします。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
大変お手数をおかけしております。
ログを上げさせていただきます。

[appended] txt

Gakuto Matsumura - Developer 返信 01/21
なんでだろう…
ドライブレターの認識そのものはCDEFGとYがとれているのに、肝心のOSのカウンターのリストが何一つかえってきてない…

Gakuto Matsumura - Developer 返信 01/21
Totalすらない…!?

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
ワイのぱそこんは実は幽霊・・?

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
すみませんすみませんすみません
lodctr /qの内容でディセーブル見落としありました
[PerfDisk] Performance Counters (Disabled)でした
レジストリエディタから値0にしたら正常動作しました

100%こちらの環境なのだからなんかあるだろうと手あたり次第起動してみていたら
パフォーマンスモニター起動時に

これらのカウンターを追加できません:

\PhysicalDisk(*)\% Idle Time
\PhysicalDisk(*)\Avg. Disk Queue Length

なるポップアップが出てヘルプの内容をもう一度実行しなおしてみていたら見落としを発見いたしました
learn.microsoft.com/ja-jp/troubleshoot/windows-server/performance/manually-rebuild-performance-counters
 このページの レジストリでカウンターが無効になっていないことを確認する セクションを参考にしてレジストリを弄ってみたら直ったようです

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
ロードキャッシュを含む のチェックを外しても動作しています。
ログにも生命感が戻りました

大変お手数をおかけしまして、申し訳ございませんでした。

[appended] txt

Gakuto Matsumura - Developer 返信 01/21
ありがとうございます!

思ったよりもこのあたりはややこしいようで、報告後に調べてみてこれかもしれないとlodctr /qに関する記載をとりあえずわかってる範囲でヘルプに書き足して作業を進めていました。
これに関してはこちらの認識と案内不足でした。

このあたりのlodctr /qの内容をレポートかなにかで実行できないかと思って、文字化け問題と格闘し、まとまったら報告しようと思いましたが、先にずばりのOSの正規なドキュメントを見つけて試してもらえたようで、丁度最適解かつ正式なものなので、ヘルプにもこのURLを追記しておきました。ありがとうございます。

レポートに突貫ではありますが、トラブルシューティング的な感じで、このlodctr /qの結果を呼び出せるようには組めたので、とりあえず現行での以下二つの未解決

・Intel HD Graphicsのレガシー(または全て)の温度がとれない問題
・「ソフトウェア描画+レイヤード+ドットフォント+文字枠+倍率指定」の条件で、文字枠にも倍率が適用されて太くなってしまう問題

の、当面解決しなさそうな2つだけかと思うので、一旦これで出してみようと思います。

後ほどまた問題等を確認されたら報告して頂けると助かります。

タスマニアの悪魔 - 2239@gziI3HF9 返信 01/21
お役に立てたようでよかったです
久しぶりにDiskIO一覧と対面出来てうれしゅうございます
ありがとうございました。

CLOSED : 追記した内容は通常通り管理人に通知されます。

update
返信

*オープンクローズ
 + 
#
thilmera project - forum
フォーラム一覧
t7b - v12.30.0.0
Original - Board v3.4 Revision(http://revision.s22.xrea.com/)
© 2001-2024 Gakuto Matsumura:弦生ささと (thilmera7gmail.com) Privacy Policy