[常に最上位] の名称を変更してほしい
-
Kuroさん、こんにちは。
今回はメニューバーの [ウィンドウ] メニューにある [常に最上位] の名称について要望があります。まず、前提としてMeryのメニューバーの構成はEmEditorのメニューバーを参考にされているのではないかと思います。
それで、EmEditorをVersion 25.0.901（プレビュー版）に更新すると、メニューバーの [ウィンドウ] メニューにある [常に最上位] の名称が [常に手前に表示] に変更されています。
よって、Meryのメニューバーの [ウィンドウ] メニューにある [常に最上位] の名称を [常に手前に表示] に変更してもらえませんか？
また、同時にオプション画面の [ウィンドウ] カテゴリにある [常に最上位の状態を保存する] についても [常に手前に表示の状態を保存する] に変更してもらえませんか？
なお、[常に手前に表示] の名称を採用している他のテキストエディタとしては下記のものが挙げられます。
- 秀丸エディタ
- サクラエディタ
- Notepad++
環境情報
Mery: 3.7.13 (x64)
Onigmo: 6.2.0
C/Migemo: 1.3
Tidy: 5.8.0
Hunspell: 1.7.1
アウトライン: 3.2.2 (Outline.dll)
Markdown プレビュー: 1.0.7 (MarkdownPreview.dll)
OS: Windows 11 (Version 24H2, OS Build 26100.3775, 64-bit Edition)| MSY-07 | 返信 -
こんばんは、ご意見ありがとうございます。
> まず、前提としてMeryのメニューバーの構成はEmEditorのメニューバーを参考にされているのではないかと思います。
ご指摘いただいた点ですが、たしかに一部の UI については、他のエディターさんの良い部分を参考にさせていただいた部分もあります。
ただ、「そっくり」や「パクリ」といった印象を与えてしまっていたとすれば、それは本意ではありません。
逆に、Mery で先に取り入れた機能が、あとから他のソフトでも採用されたケースもあったりします。そういう意味では、お互いに刺激を受けながら、それぞれの方向で進化しているのかなと思っています。
たとえば、DirectWrite の設定画面などは、Mery が先に実装していたものなんですよ。
> よって、Meryのメニューバーの [ウィンドウ] メニューにある [常に最上位] の名称を [常に手前に表示] に変更してもらえませんか？
ご提案ありがとうございます。
ちょっと前提の部分が強めだったので、最初は少し戸惑ってしまいましたが、ご意見そのものはありがたく拝見しています。
> なお、[常に手前に表示] の名称を採用している他のテキストエディタとしては下記のものが挙げられます。
こちらもご紹介ありがとうございます。
表記については、基本的に Microsoft の用語やガイドラインに沿うかたちで決めているため、他のフリーソフトに合わせる予定はありませんが、最近では Microsoft 製品でも「常に手前に表示」という表現が増えてきているようですね。
ということで、次のバージョンでは「常に手前に表示」に変更してみますね。
| Kuro | 返信 -
ご返信ありがとうございます。
> ご指摘いただいた点ですが、たしかに一部の UI については、他のエディターさんの良い部分を参考にさせていただいた部分もあります。
>
> ただ、「そっくり」や「パクリ」といった印象を与えてしまっていたとすれば、それは本意ではありません。私はMeryとEmEditor以外に「常に最上位」の名称を採用しているテキストエディタを知らないので、「EmEditorを参考にしているのかな」と思っただけで、「そっくり」や「パクリ」と思ったわけではありません。
ですが、読み返してみると確かに前提の部分が強めだったと思いました。
この件でKuroさんを不快にさせてしまったことを申し訳なく思っています。
> こちらもご紹介ありがとうございます。
>
> 表記については、基本的に Microsoft の用語やガイドラインに沿うかたちで決めているため、他のフリーソフトに合わせる予定はありませんが、最近では Microsoft 製品でも「常に手前に表示」という表現が増えてきているようですね。
>
> ということで、次のバージョンでは「常に手前に表示」に変更してみますね。確かにタスク マネージャーやPowerToysのAlways On Topでは「常に手前に表示」と表現されていますね。
では、次のバージョンでは「常に手前に表示」に変更をお願いします。それと、「常に最上位」に関してもう1つ要望があります。
それは「常に最上位」の位置を「ウィンドウ」メニューの一番上以外に変更してほしいということです。普段、私はメニューバーの「ツール」メニューにある「オプション」をクリックして、オプション画面を開いて色々設定を変更しています。
ですが、「ツール」メニューの右隣に「ウィンドウ」メニューが並んでいるため、時々勢い余って「ウィンドウ」メニューの一番上にある「常に最上位」を誤ってクリックすることがあります。
「常に最上位」をクリックしたことに気づいたときは良いのですが、たまにクリックしたことに気づかないときもあります。すると、ノートPCの画面でMeryのウィンドウを最大化しているので、タスクバーに並んでいるMery以外のアプリをクリックしてもウィンドウが切り替わらないということが発生します。
そのときに、「常に最上位」をクリックしたことに気づけば良いのですが、気づかないときはMeryがクラッシュしたと思ってしまい、わざわざショートカットキーの「Ctrl + Alt + Delete」を入力してタスクマネージャーを起動して、Meryを強制終了することがあります。そういえば、「Mery以外のタスクバーボタンをクリックしてもウィンドウが切り替わらない」の件では「常に最上位」をクリックしたことに気づかなくてお騒がせしたことがありました。
よって、「常に最上位」を誤ってクリックすることを防止するため、「ウィンドウ」メニューの一番上にある「常に最上位」の位置を下の方に移動してもらえませんか？
例えばですが、「ウィンドウ」メニューにある「すべて最小化」と「次の文書」の間に「常に最上位」を移動してはいかがでしょうか？| MSY-07 | 返信 -
> この件でKuroさんを不快にさせてしまったことを申し訳なく思っています。
いえいえ。特に不快だったわけではないのですが、まあ一応…ね。過去にちょっとあったので (察して) 😅
そんなわけで、「EmEditor さんの仕様に合わせてほしい」といった直接的なご要望については、Mery の公開を続けていくためにも、できれば控えていただけると助かります。
> よって、「常に最上位」を誤ってクリックすることを防止するため、「ウィンドウ」メニューの一番上にある「常に最上位」の位置を下の方に移動してもらえませんか？
> 例えばですが、「ウィンドウ」メニューにある「すべて最小化」と「次の文書」の間に「常に最上位」を移動してはいかがでしょうか？ご提案ありがとうございます。
実は私も、ついうっかり [常に最上位] を押してしまうことがあって、「あーまたやっちゃった…」ってなるので、メニューの位置を変えたい気持ち、わかります。
ただ、この［常に最上位］機能については、これまでもいくつかご要望をいただいたことがありまして。(たとえば、[常に最上位] の状態を保存してほしい、など)
そういった経緯もあって、この機能はあまり使わない方には邪魔に感じられるかもしれませんが、昔から使ってくださっているユーザーさんの中には、わりと活用されている方もいらっしゃるようです。
そのため、現時点でメニューの位置を一方的に変更してしまうのは、ちょっと慎重に考えてしまうところです。
とはいえ、ご要望が多ければ、改めて検討させていただきたいと思います。
| Kuro | 返信 -
タイトルバーの空いたスペースに、未保存を示す記号のように最前面を表す記号が表示されれば、一目で確認できてうれしいです。
自分は最大化したブラウザを見ながらMeryでメモを取るときなどで、最前面表示をよく使います。
そのとき、Meryを最大化にしたらブラウザに切り替わらんという、うっかりがよくあるため、最近は「最前面でポーズ」というフリーウェアを使用しています。最前面機能がないアプリやF11にアサインされていないアプリでも、任意のショートカットにアサイン出来て便利です。
Meryのメニューの最前面のチェックと連動しないのが残念なんですが仕方ないですね。むしろ連動する秀丸さんのほうが不思議。| enaka | 返信 -
> そのとき、Meryを最大化にしたらブラウザに切り替わらんという、うっかりがよくあるため、最近は「最前面でポーズ」というフリーウェアを使用しています。
情報ありがとうございます。やっぱり「最前面表示」って、一定の需要がありそうですね。
私は Microsoft の PowerToys というアプリを使っています。
こちらは
Ctrl + Win + Tのショートカットで任意のウィンドウを最前面に固定でき、さらにそのウィンドウの枠が青い縁取りになるので、視覚的にも分かりやすいですよ。【参考】「Microsoft PowerToys」Microsoft公式のシステムユーティリティ群 - 窓の杜
https://forest.watch.impress.co.jp/library/software/powertoys/> Meryのメニューの最前面のチェックと連動しないのが残念なんですが仕方ないですね。むしろ連動する秀丸さんのほうが不思議。
秀丸エディタさんで確認してみたところ、確かにメニューのチェック状態とは連動しているようですね。
ただ、ツールバー ボタンは連動していないみたいです。
システム的にウィンドウの最前面の状態を取得するには、Windows の API を叩く必要があります。
メニューの場合は [ウィンドウ] メニューを開いたタイミングでチェック状態を更新できますが、ツールバー ボタンに反映させるとなると、カーソル移動やキー入力といった操作のタイミングで都度チェックすることになり、パフォーマンス的にちょっと厳しいのかもしれません。
Mery でも [ウィンドウ] メニューの部分だけなら対応できそうな気もしますが、ツールバー ボタンとの整合性が取れていないと「どっちが正しいの？」とツッコミが入りそうで、ちょっと悩ましいところですね。
| Kuro | 返信 -
ご返信ありがとうございます。
> いえいえ。特に不快だったわけではないのですが、まあ一応…ね。過去にちょっとあったので (察して) 😅
ああ…過去にちょっとありましたね (察した) 😅
> そんなわけで、「EmEditor さんの仕様に合わせてほしい」といった直接的なご要望については、Mery の公開を続けていくためにも、できれば控えていただけると助かります。
確かに「EmEditor さんの仕様に合わせてほしい」という直接的な要望を出したのは軽率でしたね😓
今後は直接的な要望は控えますね。
> 実は私も、ついうっかり [常に最上位] を押してしまうことがあって、「あーまたやっちゃった…」ってなるので、メニューの位置を変えたい気持ち、わかります。
Kuroさんも同じうっかりをしていましたか。
> ただ、この［常に最上位］機能については、これまでもいくつかご要望をいただいたことがありまして。(たとえば、[常に最上位] の状態を保存してほしい、など)
>
> そういった経緯もあって、この機能はあまり使わない方には邪魔に感じられるかもしれませんが、昔から使ってくださっているユーザーさんの中には、わりと活用されている方もいらっしゃるようです。
>
> そのため、現時点でメニューの位置を一方的に変更してしまうのは、ちょっと慎重に考えてしまうところです。［常に最上位］機能を使用しているユーザーもいるでしょうから、メニューの位置を一方的に変更するのは慎重に考えた方が良いでしょうね。
ただ、私みたいに［常に最上位］機能を使用しないユーザーにとっては、［常に最上位］機能が［ウィンドウ］メニューの一番上というアクセスしやすい位置にあるのはどうなのかという気はしますが。
| MSY-07 | 返信 -
> Kuroさんも同じうっかりをしていましたか。
私の場合、Mery の開発やデバッグ中に [ツール] > [オプション] を開く機会が多いので、つい隣の項目を誤ってクリックしてしまうことがありますね。
とはいえ、これはトラックボール マウスを導入したことや、練習のためポインタの移動速度を自分の限界より少し速めに設定している影響もあると思うので、慣れてくれば自然と解消されていくのではないかと感じています😅
> ただ、私みたいに [常に最上位] 機能を使用しないユーザーにとっては、 [常に最上位] 機能が [ウィンドウ] メニューの一番上というアクセスしやすい位置にあるのはどうなのかという気はしますが。
お気持ちはわかります。ご要望が多ければ、位置の見直しも検討してみたいと思います。
ただ、[常に最上位] を下に移動させると、今度は [上下に分割] が一番上に来てしまいますよね。
そうなると、誤クリックによる影響は、[常に最上位] よりも大きくなる可能性があります。
たとえば、上下に分割して作業している最中に誤って [上下に分割] をクリックすると、分割が解除されてしまいます。
その場合、分割されたウィンドウ内の選択範囲もすべて解除されてしまうため、編集作業への影響は [常に最上位] の誤クリックよりも大きくなることが考えられます。
なので、なぜ [常に最上位] を誤クリックしてしまうのか、また、[常に最上位] のみを誤クリックしてしまうのなら、なぜ、他のカテゴリの一番上のメニューは誤クリックが発生しないのか、根本的な原因を探ってみるのもよいかもしれませんね。
もちろん、理想を言えば、メニューがカスタマイズできるようになるのが一番ですが…
残念ながら、Mery の開発に使用している Delphi では、メニューを動的に生成する際のパフォーマンスがあまり良くありません。
そのため、アプリの起動時にメニューを動的に構築するような仕組みを導入すると、起動速度の低下に直結してしまいます。
もともと「Mery は起動が遅い」と言われることもあり、これ以上の遅延は避けたいという事情から、カスタマイズ可能なメニューの実装は現状では難しい状況です。
ということで、もし [常に最上位] を普段お使いでない場合は、こんなマクロはいかがでしょうか？
if ((editor.QueryStatusByID(2185) & 2) !== 0) { editor.ExecuteCommandByID(2185); }[常に最上位] がオンになっていたら、それを自動で解除するマクロです。
これを [イベント] の [フォーカスを失った時] に設定しておけば、誤ってオンにしてしまっても、別のウィンドウに切り替えたタイミングで自動的に解除されます。
(ちなみに、解除と同時に別のウィンドウを前面に持ってくるには、タイトル バー部分をクリックする必要があるようです)
| Kuro | 返信 -
> 私は Microsoft の PowerToys というアプリを使っています。
一時はPowerToysを使っていたのですが、全部合わせてLibreOfficeの2倍もする巨大アプリになってしまったので、最前面でポーズ以外にも以下の類似の小粒なアプリを組み合わせて代用しています。
AutoHotKey、X-Mouse Button Control、CopyQ、Ueli、Quick Look、Everything、Everything Toolbar、Start Menu X、SumatraPDF、IME Tray64、Free42、Explorer++、RetroBar
ほぼ定番アプリでWinGetで入れられるものばかりですが、最後の4つはインストーラーがないなどでWinGetで入れられません。
http://www.neko.ne.jp/~freewing/software/imetray
https://thomasokken.com/free42
https://explorerplusplus.com/builds
https://github.com/ibillingsley/RetroBar-ThemesIME Tray64はWindows7互換モードにしないとスタートアップの起動でタスクトレイの登録に失敗し、タイムアウトするまで数分間画面がブラックアウトして固まる。
BigIME機能が手放せないが、代用がないため使い続けています。> システム的にウィンドウの最前面の状態を取得するには、Windows の API を叩く必要があります。
最前面に設定するとイベント例外が飛んできて、それ用の割込みコードを書いているものと勘違いしていました。ずっと監視する必要があるなら無理ですね。
もしイベント例外が飛んできていたなら、コンパイラ任せで無視せず握りつぶしておかないと危険かも（笑）
MS-IMEのスパイウェア紛いの振る舞いのせいで、Delphi製アプリが大迷惑したのは記憶に新しい。| enaka | 返信 -
ご返信ありがとうございます。
> ただ、[常に最上位] を下に移動させると、今度は [上下に分割] が一番上に来てしまいますよね。
>
> そうなると、誤クリックによる影響は、[常に最上位] よりも大きくなる可能性があります。
>
> たとえば、上下に分割して作業している最中に誤って [上下に分割] をクリックすると、分割が解除されてしまいます。
>
> その場合、分割されたウィンドウ内の選択範囲もすべて解除されてしまうため、編集作業への影響は [常に最上位] の誤クリックよりも大きくなることが考えられます。[上下に分割] が一番上に来ても問題はないかなと思っていましたが、分割が解除された場合のことまでは考えていませんでした。
確かに編集作業中に分割が解除されるのは問題がありますね。
> もちろん、理想を言えば、メニューがカスタマイズできるようになるのが一番ですが…
>
> 残念ながら、Mery の開発に使用している Delphi では、メニューを動的に生成する際のパフォーマンスがあまり良くありません。
>
> そのため、アプリの起動時にメニューを動的に構築するような仕組みを導入すると、起動速度の低下に直結してしまいます。
>
> もともと「Mery は起動が遅い」と言われることもあり、これ以上の遅延は避けたいという事情から、カスタマイズ可能なメニューの実装は現状では難しい状況です。起動が遅くなるのは避けた方が良いので、カスタマイズ可能なメニューの実装はしない方が良いですね。
> ということで、もし [常に最上位] を普段お使いでない場合は、こんなマクロはいかがでしょうか？
>
> [常に最上位] がオンになっていたら、それを自動で解除するマクロです。
>
> これを [イベント] の [フォーカスを失った時] に設定しておけば、誤ってオンにしてしまっても、別のウィンドウに切り替えたタイミングで自動的に解除されます。私は普段 [常に最上位] を使用しないので、上記のマクロは便利ですね。
ありがたく使わせていただきます。
| MSY-07 | 返信 -
>> enaka さん
> 一時はPowerToysを使っていたのですが、全部合わせてLibreOfficeの2倍もする巨大アプリになってしまったので、最前面でポーズ以外にも以下の類似の小粒なアプリを組み合わせて代用しています。
面白そうなツールのご紹介、ありがとうございます。
私も AutoHotKey や X-Mouse Button Control は使ったことがありますが、それ以外は初耳でした。
確かに PowerToys は便利な反面、不要な機能も盛りだくさんなので、こういった軽量ツールを組み合わせて使ったほうが、リソースの節約になりますね。
私の PC はスペックが低めなので、こういう情報はとてもありがたいです。さっそく参考にさせていただきます。
> 最前面に設定するとイベント例外が飛んできて、それ用の割込みコードを書いているものと勘違いしていました。ずっと監視する必要があるなら無理ですね。
なるほど、そう言われてみると、何らかのイベントが飛んでいる可能性はありそうですね。
Delphi でポトペタなコードばかり書いているせいか、Windows メッセージを直接拾うという発想がすっかり抜け落ちていました ^^;
試しに Spy++ で調べてみたところ、ウィンドウの位置変更メッセージ (WM_WINDOWPOSCHANGED) が届いているのを確認できました。
これは使えるかも？と思ったのですが、残念ながらそのメッセージ自体には「最前面にした」「解除した」といった情報は含まれていないようで…。
でも、WM_WINDOWPOSCHANGED をフックして、その都度 Windows API を使って「自分のウィンドウが最前面かどうか」をチェックするというアプローチなら、うまくいく可能性はありそうです。
ただこのメッセージ、ウィンドウの移動やサイズ変更のたびにバンバン飛んでくるので、そのたびに処理が走るとなると、精神衛生的にちょっとしんどいかも…？
とはいえ、私が試した範囲では特に重くなるような感じはしなかったので、実用に耐えうる可能性は十分ありそうです。
>> MSY-07 さん
> 私は普段 [常に最上位] を使用しないので、上記のマクロは便利ですね。
お役に立てそうでなによりです。
> [上下に分割] が一番上に来ても問題はないかなと思っていましたが、分割が解除された場合のことまでは考えていませんでした。
私もそこまでは考えていなかったのですが、試しに位置を変えてみたところ、「あぁん！」ってなっちゃいまして…😅
その後もいろいろと考えていたのですが、改めて原点に立ち返ってみたところ、ひとつ妙案が浮かびました。
もともと「[常に最上位] の項目の位置を変更してほしい」というご要望だったので、ついそこにばかり意識が向いていたのですが、実際の問題は…
> そういえば、「Mery以外のタスクバーボタンをクリックしてもウィンドウが切り替わらない」の件では「常に最上位」をクリックしたことに気づかなくてお騒がせしたことがありました。
…ここにあるのではないかと。
つまり、問題は「誤クリック」ではなく、「クリックしたことが視覚的に分かりづらい」ことにあるのでは？と考えました。
そこで、enaka さんの、
> タイトルバーの空いたスペースに、未保存を示す記号のように最前面を表す記号が表示されれば、一目で確認できてうれしいです。
というアイデアを参考に、ちょっと別のアプローチを考えてみました。
もちろん、タイトルバーに目印を表示する案も良いのですが、やや目立ちにくい点や、少しレガシーな印象になる可能性もあるため、今回は一旦保留とさせていただきまして…。
代わりに、Windows 11 から使えるようになった「タイトルバーとウィンドウ枠の色を変更する機能」を活用するのはどうか、という案です。
この機能、以前から存在は知っていたものの、あまり活用する機会がなさそうでスルーしていたのですが、[常に最上位] を視覚的に示す用途にはピッタリではないかと。
[常に最上位] を有効にした際に、タイトルバーと枠の色を変更する機能を実装すれば、一目で状態が分かりますし、何より Windows 11 の標準機能なので UI の一貫性も保たれます。
【参考画像】https://imgur.com/a/vvIdDmS
好みに応じて色をカスタマイズできるようにすれば、ちょっとしたオシャレ要素にもなりそうですし😋
ただし、制限事項として、[Zen モード] や [全画面表示] のときはタイトルバーや枠が非表示になるので、その場合はどうしようもありませんが…。
今後 Windows 11 のこの機能のさらに良い使い道が浮かぶ可能性もありますし、Windows 11 以降でしか使えない機能 (しかも OS レベルで若干バグっぽい挙動もある？) ということもあり、とりあえずは試験的な実装というかたちになるかと思いますが、いかがでしょうか？
| Kuro | 返信 -
ご返信ありがとうございます。
> つまり、問題は「誤クリック」ではなく、「クリックしたことが視覚的に分かりづらい」ことにあるのでは？と考えました。
はい、確かに根本的な問題は「クリックしたことが視覚的に分かりづらい」ということだと思います。
[常に最上位] はクリックしても標準バーのアイコンがオンになる以外は変化がないので、クリックしても反応がないように見えるんですよね。
> 代わりに、Windows 11 から使えるようになった「タイトルバーとウィンドウ枠の色を変更する機能」を活用するのはどうか、という案です。
>
> この機能、以前から存在は知っていたものの、あまり活用する機会がなさそうでスルーしていたのですが、[常に最上位] を視覚的に示す用途にはピッタリではないかと。
>
> [常に最上位] を有効にした際に、タイトルバーと枠の色を変更する機能を実装すれば、一目で状態が分かりますし、何より Windows 11 の標準機能なので UI の一貫性も保たれます。これは良い案だと思います😄
> 今後 Windows 11 のこの機能のさらに良い使い道が浮かぶ可能性もありますし、Windows 11 以降でしか使えない機能 (しかも OS レベルで若干バグっぽい挙動もある？) ということもあり、とりあえずは試験的な実装というかたちになるかと思いますが、いかがでしょうか？
試験的な実装というかたちで構わないので、実装してもらえると嬉しいですね😊
| MSY-07 | 返信 -
> 情報ありがとうございます。やっぱり「最前面表示」って、一定の需要がありそうですね。
>
> 私は Microsoft の PowerToys というアプリを使っています。
>
> こちらはCtrl + Win + Tのショートカットで任意のウィンドウを最前面に固定でき、さらにそのウィンドウの枠が青い縁取りになるので、視覚的にも分かりやすいですよ。最近自作のアプリではこんな感じに ”📌" \U0001F4CC (その他記号/絵文字) を使用して状態表示をしています(‘ω’)
タイトルバーのアプリ名の後ろにつけるだけなので簡単で重宝しています📌
PowerToys も使用していますがマウス操作だけで変更できるのでいろいろと重宝しています(’-’*)♪
| luna | 返信 -
> 私も AutoHotKey や X-Mouse Button Control は使ったことがありますが、それ以外は初耳でした。
AutoHotKeyとX-Mouse Button Controlは、沼（笑）
あと細かい便利ツールとライブラリとコーデックと伺かhttps://www.nirsoft.net/utils
https://the-sz.com/products
https://www.wintools.info
https://jrsoftware.org/tb2k.php
https://coolsoft.altervista.org/en/multimedia
https://codecguide.com/download_k-lite_codec_pack_basic.htm
http://ssp.shillest.net> 私の PC はスペックが低めなので、こういう情報はとてもありがたいです。さっそく参考にさせていただきます。
低め（主観）とは？
自分の場合、一般的なAI PCの仕様が確定するまで高価なPCは買い控えたいので、いまだに i5-6300U/4GB+16GB増設/SSD1TB換装のノートPCがメインです。もう一台貰い物の i5-8250UのノートPCもあるんですが、コア数2倍でもベースクロック半分で総合性能変わらず、キーボードが合わないこともあって放置中。
自作デスクトップは、i7-6700K/16GB/SSD256GB+HDD4TB のWin7からOSアップグレードしたSSDが飛んで今ではWin10を再セットアップできず放置中。Amazonで、i3-8109U/DDR4-16GB/SSD500GBの新品ミニPCが￥14,999-とか見るとちょっと考えてしまいます。
ミニPCで一般的なN100よりベースクロックと内蔵GPUが倍あるので実性能は悪くなさそうです。
ただ、もう少しだけ￥34,999- 出すと、Ryzen 7 5800H/DDR4-16GB/SSD500GBの新品ミニPCが買えてしまう。https://www.amazon.co.jp/dp/B0BB1SRBNZ
https://www.amazon.co.jp/dp/B0DZ2L3TWK> とはいえ、私が試した範囲では特に重くなるような感じはしなかったので、実用に耐えうる可能性は十分ありそうです。
人間が操作する頻度でしかウインドウ操作のイベントは飛ばないはずだから、キー入力を取りこぼすような環境でない限り、まず大丈夫そうですね。
本来ならプロファイラでどこで時間を食うのか、きちんと回数や頻度を計測すべきなんでしょうが、まずやりたくない。> もちろん、タイトルバーに目印を表示する案も良いのですが、やや目立ちにくい点や、少しレガシーな印象になる可能性もあるため、今回は一旦保留とさせていただきまして…。
>
> 代わりに、Windows 11 から使えるようになった「タイトルバーとウィンドウ枠の色を変更する機能」を活用するのはどうか、という案です。タイトルバーに目印は古い環境で実装が楽そう程度の理由なので、枠の色変更のほうが全然いいと思います。
> ただし、制限事項として、[Zen モード] や [全画面表示] のときはタイトルバーや枠が非表示になるので、その場合はどうしようもありませんが…。
最前面はウインドウモード以外では意味がなさそうなので、[Zen モード] や [全画面表示] のときは最前面を一時的に無効にして、ウインドウに戻したとき元の状態に戻るのが自然な気がします。
| enaka | 返信 -
> 最近自作のアプリではこんな感じに ”📌" \U0001F4CC (その他記号/絵文字) を使用して状態表示をしています(*'ω'*)
>
> https://imgur.com/a/qpMuF2u
>
> タイトルバーのアプリ名の後ろにつけるだけなので簡単で重宝しています📌📌もかっこいいですね。
同様のピン止めアプリを見つけましたが、使っているピンのアイコンがWin95調でややレトロです。https://github.com/thewhitegrizzli/DeskPins
https://efotinis.neocities.org/deskpins| enaka | 返信 -
>> luna さん
> PowerToys も使用していますがマウス操作だけで変更できるのでいろいろと重宝しています(’-’*)♪
ご協力ありがとうございます！[常に最上位] 機能、みなさん、意外と活用されているのですね。とても参考になります。
PowerToys もお使いとのことで、やはり外部アプリを使った最前面表示と、Mery 側の最前面表示が連動できるようになると、さらに使い勝手が良くなりそうですね。
このあたりは少し研究してみたいと思います。
> 最近自作のアプリではこんな感じに ”📌" \U0001F4CC (その他記号/絵文字) を使用して状態表示をしています(‘ω’)
スライム？Clock、かわいらしいアプリですね (*'▽')
なるほど、📌 こんな絵文字があるとは知りませんでした。
たしかに、これなら「ピン留め」の意味も一目で伝わって、わかりやすいですね。
Mery はタイトルバーにファイルのパスを表示してる都合で、どうしても長くなっちゃって、ちょっと目立ちにくいところはあるのですが、こういうアイデアは参考になります。
今後の開発の参考にさせていただきたいと思います('◇')ゞ
>> enaka さん
> AutoHotKeyとX-Mouse Button Controlは、沼（笑）
確かに (笑)
Mery に「こんな機能ほしいな～」ってご要望、実は「AutoHotKey でいけそう」なケースも多くて、あれはもう立派なスクリプト言語ですね ^^;
> あと細かい便利ツールとライブラリとコーデックと伺か
面白そうな情報をありがとうございます。
まだじっくり拝見できていませんが、ToolBar2000 をお使いとは…まさかの Delphi ユーザーさんですか！？
ちなみに、Mery のインストーラーも ToolBar2000 の作者様の Inno Setup を使わせていただいています。
「伺か」もご存知とは！懐かしいですね。まさか、今も現役で更新されているとは…。Mery のプラグインで SSP 対応ゴーストとか、ちょっと作ってみたくなりますね。
他にもツールやコーデックのお話、すごく興味深いです。
このままだと本題を忘れて雑談モード突入しそうなので、続きはまた別トピックでぜひ。
> 低め（主観）とは？
> 自分の場合、一般的なAI PCの仕様が確定するまで高価なPCは買い控えたいので、いまだに i5-6300U/4GB+16GB増設/SSD1TB換装のノートPCがメインです。わかります。私も、毎度のことながら Windows の方向性が不安で…「11、大丈夫？」となってしまい、新調を見送っています。
Mery の開発 PC は Windows 7 + Pentium® G6950、メモリ 4GB。
さらに、メイン PC も i5-4670 + メモリ 16GB で、これがいちばんのハイスペックという ^^;
(ちなみに Windows 11 は非対応です。Mery の開発どうすんの？状態ですね…)
> Amazonで、i3-8109U/DDR4-16GB/SSD500GBの新品ミニPCが￥14,999-とか見るとちょっと考えてしまいます。
それ、見ました！しかもレビューも良かったりして、ついポチりたくなりますよね。
Mery ユーザーさんからも「ミニ PC いいよ」とおすすめされることがあり、さすがに Windows 11 非対応機で頑張るのも限界を感じてきています。
でも…私の財布の中には、今、53円とレシートしか入っておりません。
> 人間が操作する頻度でしかウインドウ操作のイベントは飛ばないはずだから、キー入力を取りこぼすような環境でない限り、まず大丈夫そうですね。
> 本来ならプロファイラでどこで時間を食うのか、きちんと回数や頻度を計測すべきなんでしょうが、まずやりたくない。そうですね。その後、一応計測してみました。
さらに、イベントに含まれるフラグから「サイズ変更・位置変更」などに関わるものを判別し、それ以外をスキップする処理 (ビット演算なので軽い判定) を追加することで、動作速度にほとんど影響が出ないレベルにできそうです。
> タイトルバーに目印は古い環境で実装が楽そう程度の理由なので、枠の色変更のほうが全然いいと思います。
枠の色変更は、Windows 11 (正確には Windows 10 からありましたが、Win32 アプリ向けに解放されたのが 11) から使える機能なので、ちょっと試してみたい気持ちもありますしね。
> 最前面はウインドウモード以外では意味がなさそうなので、[Zen モード] や [全画面表示] のときは最前面を一時的に無効にして、ウインドウに戻したとき元の状態に戻るのが自然な気がします。
なるほど、確かにそれはありますね。
「ウインドウモードでは最前面で使いたいけど、Zen モード中は Alt + Tab で他のアプリに切り替えたい」っていう使い方はありそうです。
逆に「Zen モードのときは通知とか一切入ってきてほしくないから、常に最前面で！」っていう人もいそうな気もしますが…。
一応、秀丸エディタさんと EmEditor さんの挙動も確認してみたところ、全画面にしても最前面は解除されないようでした。
一度に仕様を大きく変えるのは避けたいので、まずは「最前面の状態の自動検知 (外部アプリ操作も含む)」と「枠の色変更」あたりから。
そんな感じで、本件については、いったんクローズとさせていただければと思います。
| Kuro | 返信 -
Kuroさん、Ver 3.7.14のリリースお疲れさまでした。
Ver 3.7.14を試しましたが、[ウィンドウ] の [常に最上位] が [常に手前に表示] に変更されたことで、項目の意味が分かりやすくなりました。
また、[オプション] の [ウィンドウ] カテゴリに [常に手前に表示] の [タイトル バーとウィンドウの境界線を強調表示する] が追加されたことで、[常に手前に表示] がONになっているかが分かりやすくなりました。
| MSY-07 | 返信 -
ご確認いただきありがとうございます。
> また、[オプション] の [ウィンドウ] カテゴリに [常に手前に表示] の [タイトル バーとウィンドウの境界線を強調表示する] が追加されたことで、[常に手前に表示] がONになっているかが分かりやすくなりました。
そう言っていただけると嬉しいです。
誤クリックそのものを防げるわけではありませんが、まずはこの対応で様子を見ていただければと思います。
| Kuro | 返信 -
> 誤クリックそのものを防げるわけではありませんが、まずはこの対応で様子を見ていただければと思います。
1番の問題である「[常に手前に表示] をクリックしたことに気づかない」ことが解消されたので良かったです。
上記の対応の感触を確かめたいので、しばらくは様子を見たいと思います。
| MSY-07 | 返信
