アクティブタグと非アクティブタブのコントラストを上げてほしい
-
Kuroさん
メンテお疲れさまです。
別スレッドでも少しお話していましたが、Ver 3.7.5 でのタブ機能改善で、「ボタン & 複数行 & 左揃え」ができるようになり、気に入って使っています。
ただ、しばらく使っていて、タブ数が少し多くなってくるとアクティブ/非アクティブの区別が付けづらくなってきて、一瞬で判別するのがやや難しいように思えてきました。
スクショ: https://imgur.com/a/vBYB145技術的にタブの色が調整できるのかが分からずに要望してしまい申し訳ないのですが、アクティブタブと非アクティブタブのコントラスト (色や明度の差異) を上げることはできないでしょうか？
普段ダークやマイカを設定しているのでモダンな見た目で利用させていただいていますが、今のスタイルを維持しつつコントラストを高めるとしたら、「非アクティブタブの背景色の明度を下げる」「非アクティブタブの文字色をグレーに寄せる」あたりが出来ると良さそうです。
| yuko | 返信 -
こんにちは。タブの設定、気に入っていただけて良かったです。
配色についてはかなり試行錯誤してきましたが、ダーク テーマではどうしても視認性が少し落ちてしまうことがありますね。
それでも、Mery のタブでは、アクティブなタブと非アクティブなタブの明度差を他のアプリよりも少し大きめにしています。
たとえば、いくつかのダーク テーマのアプリでのアクティブなタブと非アクティブなタブの明度差はこんな感じです。
・Mery: 13%
・Edge: 10%
・Chrome: 7%
・Visual Studio 2022: 6%
・VSCode: 3%
・メモ帳: 4%
・エクスプローラー: 4%明度差を増やしても視認性が必ず良くなるわけではなく、ディスプレイのコントラストや設定、視野角などによっても変わってくると思います。
私の環境では、DELL の 2 台のディスプレイでは問題ありませんが、三菱の 1 台は少し視認性が落ちることがあります。
特にメモ帳やエクスプローラーでは、アクティブなタブが見分けづらいこともあります。
それから、いただいたスクリーンショットを見ると、マイカ テーマを使われているようなので、これも影響しているかもしれません。
マイカ テーマはデスクトップの壁紙の色をウィンドウに反映させるため、アクティブなタブがデスクトップの暗い部分に重なると、タブが暗く見えることがあります。
アクティブなタブをもっと目立たせたい場合、[オプション] の [タブとウィンドウ] カテゴリから [アクセント カラーを使用する] をオンにすると、アクティブなタブに Windows のアクセント カラーが適用されて、視認性が良くなるかもしれません。
アクセント カラーは Windows 側の設定で自由に変更できます。
あと、アクセント カラーを [自動] に設定すると、デスクトップの壁紙の色に合わせて色が調整されるので、マイカ テーマとの相性も良いかもしれません。
よかったら、試してみてくださいね。
また、お使いの環境でメモ帳やエクスプローラー、Chrome や Edge、VSCode などのタブの色が見やすい場合は、どのアプリの色が見やすかったか教えていただけると、今後の開発の参考にさせていただきたいと思います。
| Kuro | 返信 -
> それでも、Mery のタブでは、アクティブなタブと非アクティブなタブの明度差を他のアプリよりも少し大きめにしています。
ふむ、ということは単純な明暗差以外の要素があるやもしれません🤔
> 明度差を増やしても視認性が必ず良くなるわけではなく、ディスプレイのコントラストや設定、視野角などによっても変わってくると思います。
そうなんですよね。品質低めなディスプレイほどコントラストは曖昧になりがちで、環境によりけりなところありますね。
> 特にメモ帳やエクスプローラーでは、アクティブなタブが見分けづらいこともあります。
Win 11のメモ帳やエクスプローラーの場合、「非アクティブタブの背景色はウィンドウ部分と同化、文字色の明度も落とす」をしているためか、背景色の明暗差が少ないわ割にはそこまで見分けづらさがない気がします。 (とはいえ、もうちょっとアクティブタブの背景色明度を上げてほしい感じ…)
> アクティブなタブをもっと目立たせたい場合、[オプション] の [タブとウィンドウ] カテゴリから [アクセント カラーを使用する] をオンにすると、アクティブなタブに Windows のアクセント カラーが適用されて、視認性が良くなるかもしれません。
おお、だいぶ見やすくなりました。ありがとうございます！
https://imgur.com/a/w4Lhz28> また、お使いの環境でメモ帳やエクスプローラー、Chrome や Edge、VSCode などのタブの色が見やすい場合は、どのアプリの色が見やすかったか教えていただけると、今後の開発の参考にさせていただきたいと思います。
私が使っているアプリケーションでタブ表示が見やすく感じるのは、FirefoxやEdge (「タイトルバーとウィンドウの境界線にアクセントカラーを表示する」をON状態) あたりですかね。
https://imgur.com/a/GmAVEKv前述のメモ帳もそうですが、私が見分けやすさを感じる要素として「非アクティブタブの背景色がウィンドウ色と同化している」という点が共通していそうです。
なんとなく、アクティブな箇所以外をウィンドウ色に同化させる方法は、「作業領域外をウィンドウ色にしておくと集中できるよ」というマイカの適用ポリシーの考え方に近しいものを感じますね🤔これらと比較するとMeryの場合、非アクティブタブの背景色が明るめなことから、区別しづらさを感じるのかもしれません。とはいえこれ以上非アクティブタブ背景色を暗くすると、タブ要素の区切りが分かりづらいとか、別の問題があるのかもしれませんが…
ちなみにご存知かもしれませんが、ファイルビューワのTablacus、CSSが適用できるため、私は下記のようなタブのスタイルで使っています。
Meryのタブはウィンドウ標準コントロールを利用されているとのことで、なかなかCSSのように柔軟にできるものではないと思いますが、多段タブでウィンドウ色同化な見た目のご参考になりましたら。
https://imgur.com/a/kV0fmqm| yuko | 返信 -
ご返信ありがとうございます。
> そうなんですよね。品質低めなディスプレイほどコントラストは曖昧になりがちで、環境によりけりなところありますね。
そうなんですよねー。ディスプレイによっては、明度が一定以上になると急に明るく見えたり、逆に暗く感じたりすることもあって、調整が難しいんです。
それに、有機 EL ディスプレイはダーク テーマでの効果が期待されていますが、真っ黒だと強すぎたり、少し黒っぽい色だと苦手だったりするので、暗すぎる色の使用は控えたりと、結構気を使っています。(有機 EL ディスプレイ持ってないけどw)
> Win 11のメモ帳やエクスプローラーの場合、「非アクティブタブの背景色はウィンドウ部分と同化、文字色の明度も落とす」をしているためか、背景色の明暗差が少ないわ割にはそこまで見分けづらさがない気がします。 (とはいえ、もうちょっとアクティブタブの背景色明度を上げてほしい感じ…)
Mery でも、非アクティブタブの文字色は明度を 13% 落としています。
Chrome では 11%、メモ帳では 20% 落ちているので、メモ帳ほどではないですが、許容範囲内かと思います。
> 私が使っているアプリケーションでタブ表示が見やすく感じるのは、FirefoxやEdge (「タイトルバーとウィンドウの境界線にアクセントカラーを表示する」をON状態) あたりですかね。
なるほど、Firefox では背景色の明度差が 17% ありますが、文字色は変わらないんですね。
Edge については、Windows にこんな機能があるのを初めて知りました。確かにタブが見やすいですが、私にはちょっと刺激が強すぎるかも…😅
> これらと比較するとMeryの場合、非アクティブタブの背景色が明るめなことから、区別しづらさを感じるのかもしれません。
そうですね。Mery では、ダーク テーマを開発した当時、Windows はダーク テーマ対応が遅れていて完成度も低かったため、先駆者である Mac のダーク テーマを参考に配色を調整しました。
そのため、最近の Windows アプリで使われているダーク テーマとは少し違い、やや明るめの配色になっています。
【参考画像】https://imgur.com/rHZqCXV
> とはいえこれ以上非アクティブタブ背景色を暗くすると、タブ要素の区切りが分かりづらいとか、別の問題があるのかもしれませんが…
確かにそれはありますね。タブの区切りがなくても問題なければ、背景色を暗くすることは可能です。
ちなみに、Mery ではタブにマウスを乗せたときにタブの色が背景色と同じになるのですが、その部分とアクティブタブの明度差で、yuko さんの環境だと見分けやすくなるでしょうか？
> Meryのタブはウィンドウ標準コントロールを利用されているとのことで、なかなかCSSのように柔軟にできるものではないと思いますが、多段タブでウィンドウ色同化な見た目のご参考になりましたら。
情報ありがとうございます。
Tablacus さんの名前は聞いたことがありますが、まだ使ったことはないですね。確か、Win32 アプリでダーク テーマにも自力で対応されていたと記憶していますが、すごいですよね。
私には CSS を使ったカスタマイズはちょっと難しいですが、Mery のダーク テーマも Windows 標準コントロールをハックして、自前で描画していますので、ある程度のカスタマイズは可能です。
ただし、Windows 標準コントロールの制限があるので、カスタマイズできる範囲は限られてしまいますが…。
とりあえず、試しに Mery の非アクティブタブの色と、カーソルが乗ったときのタブの色を入れ替えて、無理やり区切り線を追加してみました。(区切り線が技術的に実装できるかどうかはまだ分かりません)
個人的には、現状の方が好みなのですが、いかがでしょうか？
【参考画像 (gif 動画)】https://imgur.com/YGawrUU
| Kuro | 返信 -
> Mery でも、非アクティブタブの文字色は明度を 13% 落としています。
ありゃ、そうだったんですね。これは失礼しました。
ディスプレイのせいか私の目がぼけているのか、違いを認識できませんでした…😅> そうですね。Mery では、ダーク テーマを開発した当時、Windows はダーク テーマ対応が遅れていて完成度も低かったため、先駆者である Mac のダーク テーマを参考に配色を調整しました。
> そのため、最近の Windows アプリで使われているダーク テーマとは少し違い、やや明るめの配色になっています。なるほど。確かに参考画像のMac寄りの色合いになっていますね。
> ちなみに、Mery ではタブにマウスを乗せたときにタブの色が背景色と同じになるのですが、その部分とアクティブタブの明度差で、yuko さんの環境だと見分けやすくなるでしょうか？
そうですね、これくらいハッキリ明暗差があると見分けやすく感じます。
> とりあえず、試しに Mery の非アクティブタブの色と、カーソルが乗ったときのタブの色を入れ替えて、無理やり区切り線を追加してみました。(区切り線が技術的に実装できるかどうかはまだ分かりません)
> 個人的には、現状の方が好みなのですが、いかがでしょうか？おお、すごいです！
個人的にはかなり使ってみたい感じですが、ちょっと好みは出そうですね。固定でこの配色で適用、というのはちょっと尖りすぎ感はあるかもです。あるいは、先程教えていただいたアクセントカラーの適用でもかなり見やすくなったので、アクティブタブの背景色をカスタマイズできるようにするというのも、技術的に可能ならばありかもしれません。
例えば…
(1) アクティブタブ背景色をカスタマイズ可能とする
(2) アクティブタブ、非アクティブ両方の背景色をカスタマイズ可能とする(1) は、現状の「アクセントカラーを使用する」設定がOS設定に追従するものなのを、ユーザー独自に設定可能とさせるようにするのを想像しています。アクセントカラーに近しい色がよければ自分でそのような色味に設定する形です。あるいはアクセントカラー追従とユーザー設定のいずれかを選べたりしてもいいかもしれません。
(2) は、(1) をやるくらいならいっそ非アクティブタブも設定できるようにしちゃえ、的な案です。もし透明設定ができるのであれば、非アクティブタブはウィンドウと同化、って選択もユーザーの好みでできそうです。
ついでに、もしもこれらの色設定がテーマ設定内でできたら、テーマごとにタブ色も変えるようなカスタマイズもできて楽しいかもしれませんね🤔
| yuko | 返信 -
ご返信ありがとうございます。
> おお、すごいです！
> 個人的にはかなり使ってみたい感じですが、ちょっと好みは出そうですね。固定でこの配色で適用、> というのはちょっと尖りすぎ感はあるかもです。そうですよね。外観が大きく変わると、ユーザーさんによっては違和感を感じることもありますし、なかなかバランスが難しいところです。
> (1) アクティブタブ背景色をカスタマイズ可能とする
確かに、アクティブタブの背景色を変更したいというご要望は以前からいただいているのですが、技術的な問題、特に古い OS への対応が難しくて、手をつけられていない状況です。
というのも、Windows の標準タブコントロールには色を変更する機能がなく、自分で一からタブを描画しないといけないんです。単に色を塗り替えるだけでは済まないんですよね。
さらに、Windows XP から 11 までのすべての OS に対応するとなると、それぞれの OS に合わせたタブの見た目を再現する必要があり、かなりの作業量になるんです😱
現在の Mery では、ダーク テーマの時だけ自前で描画できるので、タブの色変更は一部のユーザーさんしか使えない機能になってしまいます。
> (2) アクティブタブ、非アクティブ両方の背景色をカスタマイズ可能とする
上記の理由から、アクセント カラーで塗りつぶしただけのシンプルなデザインなら実現可能ですが、非アクティブタブも含めてのっぺりしたデザインにしてしまうと、ライト テーマや古い OS では外観に違和感が出るかもしれません。
とはいえ、最近のバージョンでは少しずつ自前描画の対応を進めており、Windows 10 以上の環境ならライト テーマでもある程度のカスタマイズが可能になってきました。(古いスタイルの [ボタン] や [フラットボタン] には対応できていませんが…)
もし古い OS にも対応できるようになったら、タブの色変更を標準機能として取り入れるのも良いかもしれませんが、実現には時間がかかりそうです。
> ついでに、もしもこれらの色設定がテーマ設定内でできたら、テーマごとにタブ色も変えるようなカスタマイズもできて楽しいかもしれませんね🤔
将来的に、アプリ全体の外観をカスタマイズできるようになれば、GUI 部分の配色もテーマとして扱えるようにするのも良さそうですね。
ただ、現状では [表示] カテゴリの [テーマ] はエディター部分の配色に関する設定なので、GUI 部分の配色をそこに含めるのは少し違和感がありますね😅
もしタブの色を変更できるようにするなら、ちょっと地味ですが、[タブとウィンドウ] カテゴリに [アクティブなタブの色を指定する] のようなチェックボックスを設けるかたちになるかと思います。
いずれにしても、古い GUI への対応は大きな課題なので、古い OS をサポートするか、思い切ってサポートを終了するかも含めて、慎重に検討する必要がありそうですね。
| Kuro | 返信 -
> 現在の Mery では、ダーク テーマの時だけ自前で描画できるので、タブの色変更は一部のユーザーさんしか使えない機能になってしまいます。
>
> もし古い OS にも対応できるようになったら、タブの色変更を標準機能として取り入れるのも良いかもしれませんが、実現には時間がかかりそうです。
>
> いずれにしても、古い GUI への対応は大きな課題なので、古い OS をサポートするか、思い切ってサポートを終了するかも含めて、慎重に検討する必要がありそうですね。ほほー、見えないところでたくさんの努力が詰まっていたのですね…😲
古いOSでのGUI独自開発となると、なかなか労力と利用者数が見合わない状況もあるとは思いますので、カスタマイズ可能とするにしても、現行の「アクセントカラーを使用する」と同じように、特定OS・設定でしか利用できない意を込めて (試験的) 扱いとしてしまうのが開発スコープ的に良さそうな気がしますね。
ところで今更気づいたのですが、ライトテーマ & 「アクセントカラーを使用する」だと、ボタンにしている場合も独自描画？になるんですね。
カラーピッカーで見たところ、ウィンドウ部と比べタブ部で 3 だけ明るくしている様子… これ、私の目にはもう非アクティブタブがウィンドウと同化しているように見え、それでいて各タブの枠線がうっすらと見える感じ、結構好みな見た目でした。
https://imgur.com/a/FcJc0GL| yuko | 返信 -
ご返信ありがとうございます。
> 古いOSでのGUI独自開発となると、なかなか労力と利用者数が見合わない状況もあるとは思いますので、カスタマイズ可能とするにしても、現行の「アクセントカラーを使用する」と同じように、特定OS・設定でしか利用できない意を込めて (試験的) 扱いとしてしまうのが開発スコープ的に良さそうな気がしますね。
そうですね。開発に取り組むにしても、手元に XP はあるんですが、今はもう Vista や 8 は持っていないので、動作検証ができないという問題もありますし😅
確かに、古い OS を対応外にするのは現実的な選択ですが、開発者としてはやっぱり古い OS でも動作するようにしたいところです。
とりあえず、一日かかりましたが、XP で独自描画のタブに挑戦してみたところ、なんとか形にはなってきました。
【参考画像】https://imgur.com/a/j1k05wD
画像の上側がすべて独自描画のタブで、下側が XP のネイティブなタブです。
古い OS の立体的な GUI だと、タブを塗りつぶすと浮いて見えちゃいますね。
ちなみに、XP のネイティブ GUI でアクティブなタブの上にオレンジのラインが入っているのは、私が作ったわけではなく、OS の標準仕様です。
これをすべての OS で調整・検証しようとすると、相当大変そうですが…😱
> ところで今更気づいたのですが、ライトテーマ & 「アクセントカラーを使用する」だと、ボタンにしている場合も独自描画？になるんですね。
そうなんです。これが問題になっている、OS の GUI を独自描画で再現したものですね。
ライト テーマでアクセント カラーをオフにして [タブ] スタイルにすると、これが OS のネイティブな GUI です。
アクセント カラーをオンにすると、Windows 標準のタブコントロールの GUI 部品を模倣して、独自描画でそれっぽい GUI を再現しています。
模倣といっても、私が描いたわけではなく、Windows の機能で GUI 部品の元になる素材のイメージを指定サイズで生成し、それを組み合わせてタブっぽい画像を作り、ネイティブ GUI の上に重ねて描画する感じです。(なので、位置合わせや大きさの調整も大変です)
余談ですが、以前にスクロールバーで同じことをやりましたが、これもかなり苦労しましたね😅
【参考】https://www.haijin-boys.com/software/mery/mery-2-7-0#18
あと、[ボタン] や [フラット ボタン] の場合、アクセント カラーのオン/オフでデザインが大きく変わります。
これは、Windows 標準のタブコントロールの [タブ] スタイルのデザインを使って独自描画しているためです。
[ボタン] や [フラット ボタン] は XP 時代のレガシーな GUI なので、あのボタンを再現するのは非常に大変ですし、そもそもデザインが古臭いので、わざわざ再現する必要もないかなと思っています😅
というわけで、この機能の開発にはかなりの時間と労力がかかりそうなので、時間を見つけて少しずつ作り込んでいくしかなさそうです。
もちろん、OS を限った試験的な機能として先行実装することも検討してみますが、とりあえず、将来的に対応できたらいいな、というくらいの気持ちで見守っていただけると助かります。
| Kuro | 返信 -
> 確かに、古い OS を対応外にするのは現実的な選択ですが、開発者としてはやっぱり古い OS でも動作するようにしたいところです。
開発者魂、恐れ入ります…！
XPでも動作するMeryに助かっているという声もフォーラムで時折見かけますし、この根性に助けられているユーザーが一定数いるでしょうね😉> とりあえず、一日かかりましたが、XP で独自描画のタブに挑戦してみたところ、なんとか形にはなってきました。
> これをすべての OS で調整・検証しようとすると、相当大変そうですが…😱おお、これまたすごい…
もはや忘却の彼方でしたが、そういえばXP的なデザインって立体的なUIになっていましたね。ここまでがんばって調整するとは、もはや職人芸…😮> 模倣といっても、私が描いたわけではなく、Windows の機能で GUI 部品の元になる素材のイメージを指定サイズで生成し、それを組み合わせてタブっぽい画像を作り、ネイティブ GUI の上に重ねて描画する感じです。(なので、位置合わせや大きさの調整も大変です)
> 余談ですが、以前にスクロールバーで同じことをやりましたが、これもかなり苦労しましたね😅ひえぇ、想像するだけでも途方もない作業… いつも助かっています。
XP Classicに至っては、自前で素材を用意しているわけですか。これにはもう執念すら感じますね…ｗ> というわけで、この機能の開発にはかなりの時間と労力がかかりそうなので、時間を見つけて少しずつ作り込んでいくしかなさそうです。
> もちろん、OS を限った試験的な機能として先行実装することも検討してみますが、とりあえず、将来的に対応できたらいいな、というくらいの気持ちで見守っていただけると助かります。色々と楽しい裏話もありがとうございました。
ひとまずはアクセントカラーの適用で当初の問題は解消されていますので、これらの機能が実装されることをお祈りしておきたいと思います。| yuko | 返信 -
乞うご期待…と言いつつすぐにタブのアップデートを図ってきたKuroさん、流石ですｗ
タブの見た目の変更、想像以上に楽しいですね！特に、Kuroさんが紹介されていたように、フラットボタン+アクセントカラー、最高です🥰 おかげさまで、マイカも組み合わせてオシャレな上にアクティブ・非アクティブの明暗差もはっきりとするようになりました。
さらにさらに、ボタンとフラットボタンスタイルのスタイルの差別化もできて、カスタマイズしがいのある仕様になりましたね！ところで、不具合というわけではないのですが、タブを色々並べているときに気になる挙動を見つけまして…
https://imgur.com/a/QPP2Nc0
「タブを複数行にする」ONで、絶妙な位置にタブがあると、編集状態を示す「*」が付いたタイミングでタブが複数行になることがあるようです。タイピングした途端にエディタ部がガクッと動いてしまうので、もし可能ならあらかじめ「*」の幅分のプレースホルダを持たせるなどして、書き込み時にタブ幅が変わらないようになると良さそうです。
| yuko | 返信 -
横から失礼します。
この挙動はもう慣れているので、得に不満はありません。
「*」があってもなくても変化しない魔法があればいいのですが。
すべてのタブが「*」の余裕を持たせて大きくなるなら、改良とはいえません。
私の勘違いでしたらご容赦下さい。| TN24 | 返信 -
早速お試しいただき、ありがとうございます！
>> yuko さん
> 乞うご期待…と言いつつすぐにタブのアップデートを図ってきたKuroさん、流石ですｗ
実は、このアップデート、土日を全投入してやっとできたんです😭 とはいえ、「OS 限定の試験的な機能として先行実装」ってかたちにしたので、思ったより早くリリースできました。
対応しているのは Windows XP、7、10、11 だけです。Vista と 8 はテスト環境がないためごめんなさい。あと、XP のクラシック スタイルもさすがにサポートを切りましたw
> タブの見た目の変更、想像以上に楽しいですね！特に、Kuroさんが紹介されていたように、フラットボタン+アクセントカラー、最高です🥰
そう言ってもらえて嬉しいです。実は、yuko さんに教えてもらった Tablacus さんのタブから少しインスピレーションを得た部分もあるんですよ😅
> さらにさらに、ボタンとフラットボタンスタイルのスタイルの差別化もできて、カスタマイズしがいのある仕様になりましたね！
そうなんです。前のバージョンだと、スタイルの違いがあまりはっきりしていなかったので、フラット ボタンの存在感が薄かったんですよね…。
>> yuko さん、TN24 さん
> 「タブを複数行にする」ONで、絶妙な位置にタブがあると、編集状態を示す「*」が付いたタイミングでタブが複数行になることがあるようです。
これは多段タブの宿命ですね…。タブが増えると、どうしてもこういう挙動になります。
ちなみに、Visual Studio 2022、秀丸エディタさん、EmEditor さんも多段タブの場合、同じ動作をしています。
秀丸エディタさんでは、「*」の代わりにタブの文字を「太字」にするオプションがあるみたいですが。
> もし可能ならあらかじめ「*」の幅分のプレースホルダを持たせるなどして、書き込み時にタブ幅が変わらないようになると良さそうです。
タブの幅は、[指定した幅に固定] していない限り、Windows がタブの文字列に基づいて自動で決めるので、「*」の分をあらかじめ余分に取ることはできないんです。
たとえば、「*」の幅を見越して末尾に半角スペースを入れても、半角スペースと「*」の幅が一致するとは限らないので、結局微妙にタブ幅が変わってしまい、同じ問題が発生します。
やるとしたら、タブの文字列に直接「*」を表示するのではなく、VSCode のように「×」ボタンの位置に更新マークを描画するのが良さそうですが、これはちょっと難しそうです…。
> すべてのタブが「*」の余裕を持たせて大きくなるなら、改良とはいえません。
VSCode の方式なら、「×」ボタンの部分を更新マークとして使えるので、タブのサイズを変えずに対応できると思います。(「×」ボタンを非表示に設定している場合は別ですが)
> この挙動はもう慣れているので、得に不満はありません。
確かに、「*」は昔からの定番の更新マークですからね。
もし VSCode の方式を実装するにしても、オプションで選べるようにするのがいいかもしれません。できるかどうか検討してみます。
| Kuro | 返信 -
> この挙動はもう慣れているので、得に不満はありません。
> 「*」があってもなくても変化しない魔法があればいいのですが。
> すべてのタブが「*」の余裕を持たせて大きくなるなら、改良とはいえません。
> 私の勘違いでしたらご容赦下さい。いえ、おっしゃるとおりそのイメージをしていました。
これが改良となるか、ならないかは、主観と主観のぶつかり合いですので一旦意見は差し控えますが、実装を知るKuroさんが妙案を思いつく可能性もありますので、まずはコメントをお待ちしたく。なんとかうまい方法があると良いのですが…
| yuko | 返信 -
> 実は、このアップデート、土日を全投入してやっとできたんです😭 とはいえ、「OS 限定の試験的な機能として先行実装」ってかたちにしたので、思ったより早くリリースできました。
大変お疲れさまでした。より格好良くなったMery、快適に利用させていただいています。
> もし VSCode の方式を実装するにしても、オプションで選べるようにするのがいいかもしれません。できるかどうか検討してみます。
ありゃ、コメント被ってしまいましたね。
うまい方法が見つかることをお祈りいたします…！タブ関連でこれまたちょっと違った話で恐縮ですが、[閉じるボタン] 設定が「アクティブなタブの上」または「すべてのタブの上」の場合に「×」ボタン分のプレースホルダがあると思います (下記ページ1枚目)。
これにより、以下の状況があります。
・プレースホルダ分、タブ幅を取ってしまう
・「アクティブなタブの上」の場合には各非アクティブタブの右側に大きめな空白があるように見え、タブあたりの文字位置が左右非対称に見えてしまう例えばマウスオーバー時のみ「×」表示するなどしてプレースホルダを無くすオプションを用意することは難しいでしょうか？
動作イメージとして想像しているのは、Vivaldiのタブにマウスオーバーしたときの動きです。(下記ページ2枚目)キャプチャ: https://imgur.com/a/2uNYRty
無茶を言っていたらすみません…😅
| yuko | 返信 -
>> yuko さん
断定口調は失礼しました。単に私の感想でした。
ノートは狭いので、２段目までは使いたいけど、３段目となるとメイン領域の狭さを感じます。アイコンも非表示にして、なんとかタブを短くしようとしています。
どちらにしても、タブを大きくする方向にはならなさそうですね。>> Kuro さん
ご検討ありがとうございます。
「×」が「*」を兼ねるのは、どのような操作感になるのか想像がつきませんが、魔法かもしれません。何かを見落としている気がしていたのですが、分かりました。
私の使い方は、常開タブは１段目で場所を決めて使っています。これらは一軍でほぼ変化しません。それから Mery 本体のウィンドウの横幅を決めています。例の挙動を防止するために、一段目のタブが右端ぎりぎりにならないようにしています。
タブに余裕を持たせるのではなく、右端に余裕を持たせるのなら、タブの数が多くても関係ありません。技術的に可能かどうかは分かりません。
| TN24 | 返信 -
> 例えばマウスオーバー時のみ「×」表示するなどしてプレースホルダを無くすオプションを用意することは難しいでしょうか？
Vivaldi以外はどうだったかなぁと思い色々と眺めてみたところ、「×」分のプレースホルダ表示は一般的な仕様でしたね。これは無茶な要求だったと思います。失礼しました。ご放念ください🙇♂️
それに、前述のVSCode方式で編集状態を示すアイコンを表示する案にしても、「×」を表示するだけの領域が必要ですものね。
| yuko | 返信 -
>> yuko さん
> Vivaldi以外はどうだったかなぁと思い色々と眺めてみたところ、「×」分のプレースホルダ表示は一般的な仕様でしたね。これは無茶な要求だったと思います。失礼しました。ご放念ください🙇♂️
VSCode、Visual Studio 2022、Sublime Text、EmEditor さんも、やはりプレースホルダ表示を採用していますね。
一方、Windows 11 のメモ帳、秀丸エディタさん、サクラエディタさんでは、マウスオーバー時にタブの文字列の上に「×」ボタンが重なるように表示されるみたいです。
技術的には、Vivaldi のようにタブの文字列がフェードアウトするような表示は難しいですが、「×」ボタンを重ねて表示すること自体は可能だと思います。
> それに、前述のVSCode方式で編集状態を示すアイコンを表示する案にしても、「×」を表示するだけの領域が必要ですものね。
Windows 11 のメモ帳では、VSCode 方式を取り入れつつ、タブの文字列上に「×」や更新マークの「●」が重なるかたちで表示されていますので、これも一つの解決策かもしれません。
ただ、従来の更新マーク「*」だと「×」ボタンの後ろに隠れてしまいますし、VSCode 方式で「●」が表示されている場合、ファイルの拡張子あたりが隠れてしまいそうです。
>> TN24 さん
> 「×」が「*」を兼ねるのは、どのような操作感になるのか想像がつきませんが、魔法かもしれません。
確かにイメージしづらいですが、Windows 11 標準のメモ帳でそのような動作を確認できますので、もし Windows 11 をお使いであれば試してみてください。
私も最初はその「●」が更新マークだと気づきませんでしたが…^^;
> タブに余裕を持たせるのではなく、右端に余裕を持たせるのなら、タブの数が多くても関係ありません。技術的に可能かどうかは分かりません。
現在、タブは Windows 標準コントロールを使用しているため、右端 (ウィンドウの右端) に余裕を持たせる機能はなくて、その機能を新たに追加するといったことも技術的に難しいです。
yuko さんがご提案されたプレースホルダを無くす案が実現できれば、タブの幅をさらに節約することは可能かもしれませんが、見た目に違和感なく実装するには技術的な課題が多いですね。
| Kuro | 返信 -
> VSCode、Visual Studio 2022、Sublime Text、EmEditor さんも、やはりプレースホルダ表示を採用していますね。
>
> 一方、Windows 11 のメモ帳、秀丸エディタさん、サクラエディタさんでは、マウスオーバー時にタブの文字列の上に「×」ボタンが重なるように表示されるみたいです。たしかに、メモ帳などは「×」がマウスオーバーで表示される仕様になっていました。マウスオーバーで表示するというのも、言うほどニッチではなさそうですね。
VSCodeや各種ブラウザを見て「あー、プレースホルダあるのが普通なんだ」と思っていたのですが、これまた私のリサーチ不足だったようです😅> 技術的には、Vivaldi のようにタブの文字列がフェードアウトするような表示は難しいですが、「×」ボタンを重ねて表示すること自体は可能だと思います。
はい、フェードアウトのようなリッチな表示は特に不要だと思います。
> Windows 11 のメモ帳では、VSCode 方式を取り入れつつ、タブの文字列上に「×」や更新マークの「●」が重なるかたちで表示されていますので、これも一つの解決策かもしれません。
> ただ、従来の更新マーク「*」だと「×」ボタンの後ろに隠れてしまいますし、VSCode 方式で「●」が表示されている場合、ファイルの拡張子あたりが隠れてしまいそうです。メモ帳の更新マーク表示、一部文字が見切れてしまうものの、割り切りとしてはアリかもしれませんね。タブ表示幅を短くする、という目的には合致しそうです。
ちょっと想像先行な話ですが、[閉じるボタン] 設定で「すべてのタブの上 (固定)」(←これは現行通り) と「すべてのタブの上 (自動)」(←マウスオーバー表示、プレースホルダ無し) という区分だとオプション項目も統一できて良い感じかもしれません。
一方で、メモ帳のように更新マークがタブ表示文字に被るのは悩ましい問題ですね… 個人的には、拡張子表示くらいが潰れる分にはファイル名自体の判別にはほぼ影響ないので構わないのですけれどね。とはいえうまく回避できるベストな術が見つかると良いのですが。
ちなみに、これまたそういうことができるか分からず発言してしまうのですが、もしも「×」ボタンを更新マークに差し替えることができるなら、「●」でなく「＊」の形にしてみるのも良いかもしれません。 (たしかに「●」表示って更新っぽいイメージ無いですよね)
| yuko | 返信 -
ご返信ありがとうございます。
> 一方で、メモ帳のように更新マークがタブ表示文字に被るのは悩ましい問題ですね… 個人的には、拡張子表示くらいが潰れる分にはファイル名自体の判別にはほぼ影響ないので構わないのですけれどね。とはいえうまく回避できるベストな術が見つかると良いのですが。
実際に試してみたのですが、なかなか難しいですね😥
【サンプル】https://imgur.com/a/APOLApv
メモ帳みたいにアクティブなタブに「×」ボタンが常に表示されていると、やっぱり拡張子が隠れちゃいますね。
さらに、動画の途中でも試していますが、[書き換え禁止] アイコンが表示されたとき、「×」ボタンの位置をどうするかという問題も出てきました。
ちなみに、メモ帳には書き換え禁止機能がないんですよね。秀丸エディタさんではその表示がなく、サクラエディタさんだと「(上書き禁止)」という文字列がタブに追加される仕様になっていました。
また、ダーク テーマの場合は「×」ボタンの背景を塗りつぶせば問題ありませんが、ライト テーマではタブの見た目が OS のバージョンによって異なるため、適当に塗るわけにもいかないんですよね…。
レガシーな GUI を無視して、白とかで塗りつぶすという手もありますが、それは少し妥協した感じになりますね。(サンプルの 2 枚目)
> ちなみに、これまたそういうことができるか分からず発言してしまうのですが、もしも「×」ボタンを更新マークに差し替えることができるなら、「●」でなく「＊」の形にしてみるのも良いかもしれません。 (たしかに「●」表示って更新っぽいイメージ無いですよね)
VSCode 方式については、技術的に可能かまだ検討できていませんが、VSCode や Sublime Text、Windows 11 のメモ帳、最近では Visual Studio 2022 でも「●」が採用されているようです。
Visual Studio 2022 ではオプションで「*」表示に戻せるみたいですが、これからは「●」が主流になるかもしれません。
プレースホルダ無しの件については、現時点では課題が多いので、良い方法が見つかるまで実装は見送らせていただきたいと思います。
「●」方式については、技術的な課題をクリアすれば実現できると思うので、いずれ挑戦してみたいと思います。
| Kuro | 返信 -
色々と検証いただきまして、ありがとうございます🙇♂️
マウスオーバーについては何かと考慮点が多く、はたから見ても大変そうですね…。いずれ、もし良いアイデアが出ましたら、その際にでもよろしくお願いします。
「●」対応は検討続行ということで、実現できればタブ幅ずれもおきなくなりますし、とても助かります！
もし「●」が実現できるのであれば、「●」と「🔒️」は排他関係にあると思いますので、「🔒️」マークも同じ位置に表示してしまってもよいかもしれませんね。| yuko | 返信 -
ご返信ありがとうございます。
> もし「●」が実現できるのであれば、「●」と「🔒️」は排他関係にあると思いますので、「🔒️」マークも同じ位置に表示してしまってもよいかもしれませんね。
それ、いいアイデアですね！ただ、「🔒️」の上にマウスを乗せると「×」ボタンに変わるのは、ちょっとわかりにくいかもしれません。
「●」なら、なんとなくマウスを乗せたら「×」ボタンに変わっても、あまり違和感はないのですが😅
あと、「🔒️」アイコンには、ダブルクリックで [書き換え禁止] を解除するというちょっとした機能があるので、やっぱり「×」ボタンとは別に配置したほうがいいかなと思いますね。
| Kuro | 返信 -
> あと、「🔒️」アイコンには、ダブルクリックで [書き換え禁止] を解除するというちょっとした機能があるので、やっぱり「×」ボタンとは別に配置したほうがいいかなと思いますね。
これは知りませんでした…😮
そういう機能があるのでしたら、現行通りが良さそうですね。「🔒️」でもタブ幅が広がりますが、以下の特徴があると思うので、当初ご相談していた「タブが不意に広がって折り返してしまう問題」では気にしなくてよさそうです。
・ユーザーがメニュー操作で「書き換え禁止」を明示的に付ける必要があり、「*」のように意図せずに付くということは無い
・エクスプローラ側で読み取り専用になっていた場合には、ファイルを開いた時点で「🔒️」が付いているので「編集で意図せずタブ幅が広がる」ということはない> 「●」なら、なんとなくマウスを乗せたら「×」ボタンに変わっても、あまり違和感はないのですが😅
ちなみに個人的には、「●」が「×」に変わる挙動は、VSCode方式 (「●」にマウスオーバーしたときに変化) よりもメモ帳方式 (タブにマウスオーバーしたときに変化) の方が好みです。すぐ表示が変わってくれる分、タブに注意を向けたときに素早く「あ、[×] ボタンだ」と認識できる感じがしまして。
| yuko | 返信 -
ご返信ありがとうございます。
> 「🔒️」でもタブ幅が広がりますが、以下の特徴があると思うので、当初ご相談していた「タブが不意に広がって折り返してしまう問題」では気にしなくてよさそうです。
そうですね。頻繁に表示が変わるものではありませんし、もし邪魔に感じる場合でも表示をオフにできるので、現状のままでも問題なさそうですね。
> ちなみに個人的には、「●」が「×」に変わる挙動は、VSCode方式 (「●」にマウスオーバーしたときに変化) よりもメモ帳方式 (タブにマウスオーバーしたときに変化) の方が好みです。すぐ表示が変わってくれる分、タブに注意を向けたときに素早く「あ、[×] ボタンだ」と認識できる感じがしまして。
今のところ、独自描画を使用していない場合、タブのマウスオーバーはフックできないため、技術的に可能なのは VSCode や Visual Studio 2022 のように「●」にマウスオーバーした際に表示が変わる方式になるかと思います。
とはいえ、現在はフォーラム対応で手がいっぱいで、まだ検証が進んでいない状況です😅
なので、仕様を決定する前に、「●」方式が技術的に実現可能かどうか、まず確認する時間をいただけると助かります。
これまでのご要望も含めて、検証後に技術的にできること、できないことを整理して、改めてご報告させていただきますね。
| Kuro | 返信 -
先走って色々申してしまい、すみません😅
また楽しみにしつつお待ちしています。| yuko | 返信 -
いえいえ、せっかく色々とご意見をいただいたのに「やっぱり無理でしたー」ってなるのはさすがに怖いので😅
根本から作り直さないといけない部分も出てきそうなので、この金土日で、まずは試作を始める感じで進めます。いただいたご意見を参考にしつつ、ゆっくり進めていけたらと思っています。
もちろん、ご意見はしっかり参考にさせていただきますが、現時点では仕様的に少し厳しいところもあります。
今週も土日をつぶすのは正直ちょっとつらいですがw、ほどほどにがんばるので、気長に待っていただけると嬉しいです😱
| Kuro | 返信 -
お待たせしました。精神と時の部屋から無事 (？) 帰還しました⌛😫
さて、VSCode のようにタブの更新マーク「*」を「●」に変更する機能について、技術的な検証や仕様、ご要望を整理しましたので、共有しますね。
まず、最大の問題は「タブにマウスオーバーしたときに反応」が実装できなかったことです。
ダーク テーマのように独自描画している場合はなんとかなるかもと思いましたが、ライト テーマの OS ネイティブ UI にはその機能がなくて、ゼロから作るにはちょっと無理がありました。
そこで、「タブのマウスオーバー」を使わない前提で、以下の仕様を考えてみました。
---
仕様:
・タブの更新マーク「*」を非表示にする
・タイトルバーの更新マーク「*」はそのまま
・更新時、タブの「×」ボタンを「●」に変更し、ボタンにマウスオーバーすると「×」に戻る
・「×」ボタンをクリックでタブを閉じるオプション項目名: [ダーティ インジケーターをドットで表示する]
※「ダーティ インジケーター」は更新マークを指す用語で、「ドット」という表現も Microsoft の用語に準拠しています。
問題点:
・タブ設定で [閉じるボタン] が [無し] または [ウィンドウの右端] に設定されている場合、「×」ボタンが表示されない対応案:
(1) 「×」ボタンがない場合は「●」を表示しない
(2) 「×」ボタンがなくても余白を確保して「●」を表示、ボタンにマウスオーバーで「×」に変える提案: 設定に反してボタンが表示されてしまいますが、使えないよりはマシ！ということで、(2) 案が現実的かなと思っています。
---以上が、現時点での Mery の仕様と技術的な課題を踏まえた実現可能な範囲です。
---
【その他の検討事項】(1) プレースホルダ無しで、タブの文字列に「×」ボタンを重ねる案
・問題: タブのマウスオーバーは独自描画設定 (ダーク、または、ライト + アクセントカラー) でしか実装できない
・問題: タブの文字列 (拡張子) が隠れてしまう
・問題: 書き換え禁止マーク「🔒」と競合する(2) 「🔒」マークを「×」や「●」と同じ位置に表示する案
・問題: 更新されたテキストでも書き換え禁止にできるため、「🔒」と「●」は排他ではない
・問題: 「🔒」のダブルクリックで書き換え禁止を解除する動作が「×」ボタンと競合する(3) タブにマウスオーバーで「●」を「×」ボタンに変える案
・問題: タブのマウスオーバーは独自描画でしか動作しない
・問題: タブにマウスを乗せるだけで更新マークが消え、更新状態を見逃す恐れがある
---技術的には「タブのマウスオーバーが独自描画設定でしか動作しない」という問題が解決できたとしても、(1) や (2) には他にも課題が多いので、現時点では難しいかなと思っています。
また、ライト テーマの OS ネイティブな UI を犠牲にするのも悩みどころです。
ご提案いただいたアイデアは却下というわけではありませんが、技術的な問題がクリアできて、もっと良いアイデアが出てきたら、また改めて検討させていただきますね。
| Kuro | 返信 -
> お待たせしました。精神と時の部屋から無事 (？) 帰還しました⌛😫
大変な調査、ありがとうございました😭
> まず、最大の問題は「タブにマウスオーバーしたときに反応」が実装できなかったことです。
あくまで好みの範疇でしたので、VSCodeのように「×」マウスオーバーでも十分かと思います。
> そこで、「タブのマウスオーバー」を使わない前提で、以下の仕様を考えてみました。
仕様に関して、特に異論なしです。
> 問題点:
> ・タブ設定で [閉じるボタン] が [無し] または [ウィンドウの右端] に設定されている場合、「×」ボタンが表示されない
>
> 対応案:
> (1) 「×」ボタンがない場合は「●」を表示しない
> (2) 「×」ボタンがなくても余白を確保して「●」を表示、ボタンにマウスオーバーで「×」に変える
>
> 提案: 設定に反してボタンが表示されてしまいますが、使えないよりはマシ！ということで、(2) 案が現実的かなと思っています。こちらも異論なしです。
仰るように若干の違和感は残るものの、そもそもオプションでONにするものですので、見た目の好みに応じて組み合わせてください、というスタンスが取れるので良いかと思います。> オプション項目名: [ダーティ インジケーターをドットで表示する]
個人的に、「ダーティ インジケーター」というカタカナ表記だけ、何を示しているのかややピンと来ないかも、とほんのり懸念しました。例えば、「編集中状態をドットで表示する」などの方が、意味しているところが明らかな感じがします。
ITをやっている身としては「ダーティ」も「インジケーター」もしばしば耳にする言葉なので「ああ、確かに保存前の一時データはダーティだよね」みたいなイメージが湧くので分かるのですが、そういうイメージが無いとピンと来ないかも…とちょっと思いました。
(でも、ググったところ、Visual Studioでは上記の単語がオプションに使われているようですね)とはいえ、事の経緯を知っている身としては上記の言葉の意味もすんなり通じるので反対というほどではなく、一応程度のコメントでした。
> ご提案いただいたアイデアは却下というわけではありませんが、技術的な問題がクリアできて、もっと良いアイデアが出てきたら、また改めて検討させていただきますね。
諸々、お時間とって調べていただいて、ありがとうございました！
小さな機能に見えてもこれだけ多岐にわたる検討要素があり、さらにそれを隅々まで調べる根性と親切さに、頭が上がりません🙇♂️| yuko | 返信 -
> お待たせしました。精神と時の部屋から無事 (？) 帰還しました⌛😫
休日の検証作業お疲れさまでした。
> 仕様:
> ・タブの更新マーク「*」を非表示にする
> ・タイトルバーの更新マーク「*」はそのまま
> ・更新時、タブの「×」ボタンを「●」に変更し、ボタンにマウスオーバーすると「×」に戻る
> ・「×」ボタンをクリックでタブを閉じる「ボタンにマウスオーバー」を設定しているときは、タイトルバーの更新マークは「●」の方が良いと思います。
というのも、タブの更新マークは「●」なのに、タイトルバーの更新マークが「*」だと、更新マークが統一されていなくて分かりづらいと思ったからです。それと、VSCodeではタスクバーのファイル名の先頭に更新マーク「●」（Windows 11のメモ帳では更新マーク「*」）が表示されます。
よって、Meryでもタスクバーのファイル名やフルパスの先頭に更新マーク「●」が表示されると分かりやすいと思います。また、下記の隠しオプションをMery.iniの [File] セクションに追記すると、タスクバーのファイル名の表示方法が変わります。
・ShowFullPath=0：Meryがアクティブ時でもタスクバーにファイル名のみが表示
・NoFullPathIfNotActive=0：Meryが非アクティブ時でもタスクバーにファイル名をフルパスで表示よって、これらの隠しオプションを使用しているときも、タスクバーのファイル名の先頭に更新マーク「●」が表示されると更新されているかが分かりやすいと思います。
なお、興味のある方は下記フォーラムか、MeryWikiのマクロライブラリとプラグインライブラリにある「隠しオプション一覧」を参照してください。
https://www.haijin-boys.com/discussions/7651
https://www.haijin-boys.com/wiki/隠しオプション一覧#タイトルバーの表示名> 問題点:
> ・タブ設定で [閉じるボタン] が [無し] または [ウィンドウの右端] に設定されている場合、「×」ボタンが表示されない
>
> 対応案:
> (1) 「×」ボタンがない場合は「●」を表示しない
> (2) 「×」ボタンがなくても余白を確保して「●」を表示、ボタンにマウスオーバーで「×」に変える(2)で問題ないと思います。
> 【その他の検討事項】
>
> (3) タブにマウスオーバーで「●」を「×」ボタンに変える案
>
> ・問題: タブのマウスオーバーは独自描画でしか動作しない
> ・問題: タブにマウスを乗せるだけで更新マークが消え、更新状態を見逃す恐れがある(3)に関しては、タブにマウスを乗せるたびにボタンが変化するのが鬱陶しいので好みではないです。
| MSY-07 | 返信 -
>> yuko さん、MSY-07 さん
ご返信とご意見、ありがとうございます。
少し長くなりそうなので、すでに同意いただいた部分は省略して、回答させていただきますね。どうかご了承ください。
> 個人的に、「ダーティ インジケーター」というカタカナ表記だけ、何を示しているのかややピンと来ないかも、とほんのり懸念しました。
そうなんですよね、私もそこは悩みました。「ダーティ インジケーター」で検索すると食洗機しか出てこないし😅 (しかもドットじゃないし！みたいな感じでw)
ただ、独自の用語を作るのも Mery 的には好ましくないので、Microsoft 製品を調べてみたのですが、これだ！というものが見つからず…。
VSCode だと「アクティブなエディターの変更が保存されていない場合を示すインジケーター」なんて表記になっていて、ちょっと長すぎるかなって思います。
もう少し Microsoft の用語を組み合わせて、他に良い表現がないか探してみますね。
> 小さな機能に見えてもこれだけ多岐にわたる検討要素があり、さらにそれを隅々まで調べる根性と親切さに、頭が上がりません🙇♂️
いえいえ、趣味の一環なので、ついつい細かいところまでこだわっちゃうんです😅
仕事だったら「はい、すぐ実装します！」ってなるんですけどねw
> 「ボタンにマウスオーバー」を設定しているときは、タイトルバーの更新マークは「●」の方が良いと思います。
他のアプリも見てみたのですが、最近のアプリってそもそもタイトルバーがないものが多いんですよね。なので、ここは現状維持でもいいかなって思ってました。
> VSCodeではタスクバーのファイル名の先頭に更新マーク「●」（Windows 11のメモ帳では更新マーク「*」）が表示されます。
なるほど、VSCode やメモ帳はタスクバーに更新マークを表示していたのですね。それは気づきませんでした。
タスクバーの文字列はタイトルバーの内容がそのまま反映されるみたいなので、これは確かに参考になりそうです。
VSCode が「●」を使ってるなら、それに合わせても良さそうですね。
Visual Studio 2022 にタイトルバーが表示できる設定があることに気づき、試してみたら、やっぱり「●」マークが使われていました。
> よって、Meryでもタスクバーのファイル名やフルパスの先頭に更新マーク「●」が表示されると分かりやすいと思います。
確かに、今の仕様だとファイル名やフルパスの末尾に「*」が表示されるので、タスクバーにフルパスが表示されると末尾の「*」が見えなくなりますね。
だからこそ、VSCode やメモ帳は先頭に更新マークを付けているのかもしれませんね。Visual Studio 2022 は末尾でしたけど…。
それを考えると、従来の「*」マークも先頭にした方がいい気もしますが、タブでは末尾に「*」、タイトルバーやタスクバーでは先頭に「*」だとちょっとチグハグな感じになりますね。
タブの「●」も末尾にあるし、多少チグハグでも大丈夫かな…🤔
というわけで、整理すると…
・「ボタンにマウスオーバー」を設定しているときは、タイトルバー (タスクバー) の更新マークも「●」にする
→ VSCode や Visual Studio 2022 でも「●」が使われているので、これを採用するのはアリですね。
・タイトルバー (タスクバー) の更新マーク「●」は先頭に表示
→ これも VSCode に倣って採用するのが良さそうです。(ただし Visual Studio 2022 は末尾でしたが…)
・従来の「*」マークをどうするか？
案 1. 更新マークを先頭に表示するのは、「ボタンにマウスオーバー」を設定 (「●」マークを使用) しているときだけ
→ これは新機能なので、従来のユーザーさんへの影響は少なそうです。
案 2. タブの「*」は今までどおり末尾、タイトルバー (タスクバー) では先頭に「*」を表示
→ 長いファイル名だとタスクバーの「*」が見えなくなる問題を解決できるので、これなら従来のユーザーさんも納得してくれそうです。
案 3. タブの「*」もタイトルバー (タスクバー) の「*」も先頭に表示
→ さすがにタブの「*」の位置を変えると違和感を持つユーザーさんもいるかもしれません。
→ でも、タブ設定の [指定した幅に固定する] のとき、末尾で「*」が切れるより先頭にあったほうがいい気もします。
→ (とはいえ、[指定した幅に固定する] のとき、末尾の拡張子と「*」マークが切れてしまう問題の対策は、その後、開発中なんですけどね)→ 先頭にするか末尾にするかをオプションで選べるようにするのは…さすがに大変ですね😱
> よって、これらの隠しオプションを使用しているときも、タスクバーのファイル名の先頭に更新マーク「●」が表示されると更新されているかが分かりやすいと思います。
そうですね！これは実装を見落としがちな部分なので、注意しておきます。
ということで、私の方でももう少し考えてみますが、上記の内容で何か気づいた点やご意見があれば教えていただけると嬉しいです😊
| Kuro | 返信 -
>> Kuroさん
> > VSCodeではタスクバーのファイル名の先頭に更新マーク「●」（Windows 11のメモ帳では更新マーク「*」）が表示されます。
おお… 私もこの点には気づかず😯 MSY-07さんの鋭さに驚きです。
Kuroさんも仰っているように、タイトルバー = タスクバーの内容になっているように見えますね。
タスクバーの内容になっているということは、 Alt+Tab でのサムネイルのタイトル表示でも使われていますね。ちなみにですが、AutoHotkeyのWindow Spy機能でVSCodeのタイトル文字列をコピーしてみたところ、先頭の更新の丸記号はよくある「● (U+25CF)」でした。
> ・「ボタンにマウスオーバー」を設定しているときは、タイトルバー (タスクバー) の更新マークも「●」にする
> ・タイトルバー (タスクバー) の更新マーク「●」は先頭に表示タスクバー等での表示において見切れないというメリットの他、更新状態はファイル名の長さを問わず必ずタイトル表示の左端位置を見ればいい (視点の固定化)、という点で良さそうに感じます。
気づいていなかった身でありつつアレですが、先頭位置に表示、賛成です。> ・従来の「*」マークをどうするか？
『案 2. タブの「*」は今までどおり末尾、タイトルバー (タスクバー) では先頭に「*」を表示』が良さそうに感じます。
前述の通り、タスクバー (と Alt+Tab 表示) で見える、更新状態を確認するにあたりタイトルバー上で視点位置を左端固定にできる、というメリットがあるのは良さそうです。
また、「ボタンにマウスオーバー」のON/OFF 問わず、タブでは右側を見れば編集状態が見えるということで、ON/OFF いずれの状態でも統一している感もあるように感じます。
| yuko | 返信 -
> ・従来の「*」マークをどうするか？
従来の「*」マークに関しては、案2が良いと思います。
ちなみにですが、Notepad++ではタイトルバー（タスクバー）の先頭に「*」マークが表示される仕様ですね。
また、Notepad++ではタブのフロッピーディスクのアイコンの色が青から赤に変化することで、更新されたかどうかを表現しているみたいですね。
| MSY-07 | 返信 -
>> yuko さん、MSY-07 さん
ご返信ありがとうございます。
> ちなみにですが、AutoHotkeyのWindow Spy機能でVSCodeのタイトル文字列をコピーしてみたところ、先頭の更新の丸記号はよくある「● (U+25CF)」でした。
情報ありがとうございます。おっしゃるとおり、VSCode のソースコードにもバッチリ「●」と書かれてました。
フォントによっては「●」はちょっと大きすぎる気もしますが…
というわけで、試しにタイトルバーの先頭に「●」を表示してみました。
※タブの「●」は画像なので、今回はそこは気にしないでくださいね。
【キャプチャ - Windows 10】https://imgur.com/a/mreeKJF
タイトルバーのないアプリでは気になりませんが、この大きな「●」がタイトルバーの先頭に出たり消えたりするのは、ちょっと目につきますね😅
ちなみに、Windows 11 だと「●」は少し小さめに表示されるようです。
【キャプチャ - Windows 11】https://imgur.com/a/8nnsLTg
ただ、更新マークが表示されるたびにファイル名全体が右にずれるので、編集や保存を繰り返すと、このズレが結構気になります。
そこで、他のエディターの仕様も調べてみました。(順不同)
海外製エディター
- メモ帳: 先頭、「*」
- VSCode: 先頭、「● (U+25CF)」 + 「半角スペース (U+0020)」
- Visual Studio 2022: 末尾、「半角スペース (U+0020)」 + 「⬤ (U+2B24)」
- Sublime Text: 末尾、「半角スペース (U+0020)」 + 「• (U+2022)」
- Brackets: 先頭、「• (U+2022)」 + 「半角スペース (U+0020)」
- Notepad++: 先頭、「*」
- Vim: 末尾、「半角スペース」+「+」
- Atom: 表示なし
- IntelliJ IDEA: 表示なし
国産テキストエディター
- 秀丸エディタさん: 末尾、「(更新)」
- EmEditor さん: 末尾、「半角スペース」+「*」
- サクラエディタさん: 末尾、「(更新)」
- TeraPad さん: 末尾、「半角スペース」+「*」
- WZ EDITOR さん: 末尾、「(変更)」
- MIFES さん: 末尾、「(変更あり)」
さらに、ユニコードの時代になって「*」は「• (U+2022)」に置き換えられているという情報もありました。たとえば、パスワード入力欄や箇条書きリストなどです。
- Windows のログイン画面: 「● (U+25CF)」 (たぶん)
- Edge のパスワード入力欄: 「• (U+2022)」 (たぶん)
- Chrome のパスワード入力欄: 「• (U+2022)」 (たぶん)
- Markdown の箇条書きリスト: 「• (U+2022)」 (？)
ということで、以下の 2 点について考えてみる必要がありそうです。
検討事項 (1)
更新マークは「● (U+25CF)」か「• (U+2022)」のどちらが適しているか？
ちなみに、それぞれのユニコードの名前はこうなっています。
- • (U+2022): BULLET
- ● (U+25CF): BLACK CIRCLE
- ⬤ (U+2B24): BLACK LARGE CIRCLE
「● (U+25CF)」はちょっと大きすぎるし、「• (U+2022)」は逆に小さすぎる…。このあたり、微妙なところですね。
Visual Studio 2022 が「⬤ (U+2B24)」を使っている理由は謎ですが、これはプログラムミスの可能性もありますね🤔
ただ、次の検討事項 (2) を考慮すると、答えが見えてくるかもしれません。
検討事項 (2)
更新マークを先頭に表示するか、末尾に表示するか？
先頭
メリット:
- タスクバーでも更新マークが隠れない。
デメリット:
- 「*sample.txt」より「sample.txt *」の方がファイル名が読みやすい。
- 更新マークの表示/非表示が切り替わるたび、ファイル名全体が左右に動いてしまう。
- ウィンドウをタイトル順に並べ替える機能や、そういったアプリがあれば影響が出る可能性がある。
末尾
メリット:
- ファイル名の視認性が良く、更新マークの表示/非表示が切り替わっても邪魔にならない。
デメリット:
- タスクバーでは更新マークが見えなくなることがある。
以下のサンプルを見てください。
【キャプチャ】https://imgur.com/a/7CIVDIe
(1) 先頭、「● (U+25CF)」 + 「半角スペース (U+0020)」
(2) 先頭、「• (U+2022)」 + 「半角スペース (U+0020)」
(3) 末尾、「半角スペース (U+0020)」 + 「● (U+25CF)」
(4) 末尾、「半角スペース (U+0020)」 + 「• (U+2022)」
ここからは、私なりの考察と提案です。
なんとなくですが、古いエディターは更新マークを末尾に表示することが多いようです。
ちなみに、メモ帳の更新マークは Windows 10 Build 18298 (19H1) から実装されたようで、最近は先頭に表示するのがトレンドっぽいですね。
案 1. 末尾に「半角スペース (U+0020)」 + 「• (U+2022)」
キャプチャの (4) に該当します。この方法の良いところは、更新マークが視界の邪魔にならないところです。
タスクバーはウィンドウの切り替えに使うことが多いので、更新の有無よりもファイル名がちゃんと見えることを優先しています。
ただ、末尾の「• (U+2022)」がちょっと目立たないかもしれませんね。
案 2. 先頭に「• (U+2022)」 + 「半角スペース (U+0020)」
キャプチャの (2) に該当します。「● (U+25CF)」よりも、小さな「• (U+2022)」を先頭に置くことで、表示/非表示の切り替え時のファイル名のズレを少し軽減できます。
先頭だと「• (U+2022)」でも目立つので、視認性も確保できます。
また、箇条書きなどでよく使われる記号なので、ファイル名の前に置くのも自然です。
案 3. 先頭に「• (U+2022)」のみ
半角スペースなしでズレを最小限に抑えた案です。
メモ帳の「*」もスペースなしで先頭に付いていますし、これもアリかなと思いましたが、「• (U+2022)」だとファイル名にくっつきすぎて、美しくないですね😱
【キャプチャ】https://imgur.com/a/rqBwnX2
上が「• (U+2022)」、下が「*」です。「*」だと気にならないのですが…。
なので、案 2 と組み合わせて、「• (U+2022)」にはスペースを入れて、「*」にはスペースなしというのも良いかもしれませんね。
案 4. 先頭に「*」のみ
設定にかかわらず、先頭に「*」を表示する、いわゆるメモ帳準拠の案です。
「*」だけの場合は幅が狭いため、更新マークが表示されてもファイル名のズレが少なくて済みます。
メモ帳と同じ仕様なので、安心感があるのもポイントです。
案 5. 現状維持
一周回って現状維持の案です。設定にかかわらず、末尾に「 *」を表示します。
タスクバーでは、更新マークの有無よりもファイル名がちゃんと見えることが大事です。
更新マークが表示されてもファイル名の位置は変わらないので、視界の邪魔にもなりません。
やはり、昔から慣れ親しんだ仕様には安心感がありますね。
以上のようにアイデアを整理してみましたが、それぞれに一長一短があり、悩ましいところです。
他にもオプション項目名など検討事項がありますが、ひとまずこの内容を検討し、別件についてはまた後日考えたいと思います。
| Kuro | 返信 -
引き続きの検証、ご苦労さまです。
おっしゃるようにタイトルバーありのアプリケーションなので、Win 10 の ● (U+25CF) だと確かに目に付く大きさですね…🤔
一方、 • (U+2022) だと、これまたKuroさんと同感で、ちょっと小さいなと感じます。
個人的には、
・先頭、「*」
・末尾、「半角スペース」+「*」 ※現行と同じ
が見栄えのバランスが良いような気がしています。私自身は、タイトルバーに「*」が付いていることを意識したことすらあまりなかった人間なので、編集を始めたときにファイル名が半角1文字ほど右に動いても気にならないかなぁと思いました。(さすがに ● くらい大きなものが表示されるとその見た目に ｷﾞｮｯ としますが😅)
あと、タイトルバー表記をあまり気にしたことがないの、何故かなぁなんてぼんやりと考えてみたのですが、タブ表示に慣れ親しんでいるからかも、なんて思いました。
先頭「*」の最大のメリットである、タスクバーや Alt+Tab 時にファイル名の長さを問わずに更新マークを表示できるという点、最大のメリットを享受できるのはSDI (タブOFF) で使っているときなんでしょうね。あるいは、秀丸やEdgeのように、タスクバーのマウスオーバーで開いているタブがすべてサムネイル表示されるアプリケーションにおいても、先頭に更新マークがあると同じ理由で嬉しいかもしれません。
ちなみに一応、先頭「*」の雰囲気を見てみようかと notepad++ を使ってみましたが、やはり私には気になりませんでした。(タイトルバー表示が、文字入力中の視野には入っていない感じ)
| yuko | 返信 -
案5（現状維持）がいいと思います。
Notepad++で検証しましたが、更新マークの表示/非表示が切り替わるたび、タイトルバーのファイル名全体が左右に動くのが気になってしまうので、更新マークは末尾に表示するのがいいですね。
また、タスクバーの先頭に更新マークがあると、表示/非表示が切り替わるたびにファイル名が左右に動くのが気になりますね。
それと、タイトルバーの更新マークは「*」の方がしっくりきますね。
と言いましたが、実は私もタブで更新マークを確認しているので、タイトルバーで更新マークを確認することはないんですよね。
よって、下記の案6を考えてみました。
## 案 6. タイトルバーの廃止
以前、このフォーラムでKuroさんが「最近のアプリってそもそもタイトルバーがないものが多いんですよね」と発言していたので、いっそのことタイトルバーを廃止するものありかなと思いました。
タイトルバーがなくなればデザイン的にもスッキリしますし。
ただ、タイトルバーを廃止すると、SDIのときにファイル名が表示されなくなるので、SDIを使用している人は困りますね。
| MSY-07 | 返信 -
>> yuko さん、MSY-07 さん
ご返信ありがとうございます。
> 編集を始めたときにファイル名が半角1文字ほど右に動いても気にならないかなぁと思いました。
一度だけなら気にならないかもしれませんが、私の場合は Ctrl + S を頻繁に押す癖がついているので、カクカクするのがちょっと気になりますね😊 慣れるまで少し時間がかかるかもです。
> 最大のメリットを享受できるのはSDI (タブOFF) で使っているときなんでしょうね。
確かに、SDI モードだと Alt + Tab がタブ切り替えの代わりになりますね。
ただ、Alt + Tab で表示される画面は、開いているウィンドウの数によっても違いますが、そこそこ大きいですし、フルパスではなくファイル名のみが表示されるので、末尾に「*」でも隠れることは少ないかもしれませんね。
> あるいは、秀丸やEdgeのように、タスクバーのマウスオーバーで開いているタブがすべてサムネイル表示されるアプリケーションにおいても、先頭に更新マークがあると同じ理由で嬉しいかもしれません。
Mery の SDI モードに似た感じですね。
Mery ではそのレイヤーを SDI モードに割り当てていて、そのレイヤーの上にタブ機能があるので、タブレベルでサムネイル表示するのは難しいですが…。
> ちなみに一応、先頭「*」の雰囲気を見てみようかと notepad++ を使ってみましたが、やはり私には気になりませんでした。(タイトルバー表示が、文字入力中の視野には入っていない感じ)
> Notepad++で検証しましたが、更新マークの表示/非表示が切り替わるたび、タイトルバーのファイル名全体が左右に動くのが気になってしまうので、更新マークは末尾に表示するのがいいですね。
ご意見ありがとうございます。意見が分かれますね🤔 私はどちらかというと気になる派ですが、ユーザー側ではなく開発者側から見ると、メモ帳準拠という建前も捨てがたいところです。
> ## 案 6. タイトルバーの廃止
> 以前、このフォーラムでKuroさんが「最近のアプリってそもそもタイトルバーがないものが多いんですよね」と発言していたので、いっそのことタイトルバーを廃止するものありかなと思いました。
タイトルバーがないと言っても、完全にないわけではなく、タブと一体型になっているんですよね。
こういったアプリ、たとえば Windows 11 のメモ帳やターミナルは、Windows 10 以降で対応している、WinUI 3 フレームワークを使って開発されています。
一年ほど前に Microsoft が提供を開始した「XAML Islands」を使えば、Mery のような Win32 アプリからも WinUI 3 コントロールを使用できるようになるらしいです。
でも、今のところ、Mery の開発環境である Delphi は WinUI 3 コントロールをサポートしていません。
Delphi の公式サイトには「今後の展開にどうかご期待ください」と記載されているので、将来的に対応される可能性はあると思います。
そういうわけで、現時点では、タイトルバーのないアプリ化は Mery では難しいですね。
話が少し脱線しましたが、yuko さんは案 4 または 5、MSY-07 さんは案 5 ということで、最終的には案 5 (現状維持) にしましょうか。
ただ、実は案 4 と 5 は元々考えていなかったんです。
案 3 まで書いて投稿しようとしていたのですが、急遽選択肢として追加したんですよね。
なので、個人的には案 2 の「先頭に「• (U+2022)」+「半角スペース (U+0020)」」になるかなと予想していました😅
時間がかかって結局元通りになったのは少し脱力ですが、きちんと検討した結果ですので、受け入れますね。
ご協力ありがとうございました！
それから、オプション項目名ですが、適切な言葉が見つからなかったので、結局「ダーティ インジケーター」にしようかなと思っています。
Mery では「インジケーター」という用語はすでに使われているので、あとは「ダーティ」だけですが、この用語も「未保存の変更」などと表現するよりシンプルで良いかなと😊
| Kuro | 返信 -
Kuroさん、ご返信ありがとうございます。
> でも、今のところ、Mery の開発環境である Delphi は WinUI 3 コントロールをサポートしていません。
>
> Delphi の公式サイトには「今後の展開にどうかご期待ください」と記載されているので、将来的に対応される可能性はあると思います。
>
> そういうわけで、現時点では、タイトルバーのないアプリ化は Mery では難しいですね。DelphiがWinUI 3コントロールをサポートするまではこの話は保留ですね。
> 話が少し脱線しましたが、yuko さんは案 4 または 5、MSY-07 さんは案 5 ということで、最終的には案 5 (現状維持) にしましょうか。
yukoさんも案 5 (現状維持) を推しているので、案 5でいいと思います。
> 時間がかかって結局元通りになったのは少し脱力ですが、きちんと検討した結果ですので、受け入れますね。
提案した身としては、色々お手数をかけてすいませんでした。
> それから、オプション項目名ですが、適切な言葉が見つからなかったので、結局「ダーティ インジケーター」にしようかなと思っています。
>
> Mery では「インジケーター」という用語はすでに使われているので、あとは「ダーティ」だけですが、この用語も「未保存の変更」などと表現するよりシンプルで良いかなと😊「ダーティ インジケーター」でいいと思います。
| MSY-07 | 返信 -
諸々、ご検討に多くの時間を割いていただきまして、ありかとうございました🙇♂️
最終的に決定された各事項について、十分に議論されましたし、異論ありません。
ダーティインジケーターの搭載、楽しみにお待ちしています😉| yuko | 返信 -
Kuroさん
ダーティインジケータ対応、ありがとうございました & お疲れ様でした。
タブ幅が変わらなくなったのはもちろん嬉しいですが、それに加え、更新が掛かっているタブがぱっと見ですぐ分かるようになって、とてもいい感じです。
今回のアップデートもなかなか盛り盛りですね。特に、アウトラインプラグインの件はありがとうございます。MarkdownのコメントブロックでShell Script書くのが益々快適になります😊
ところで、確認のためにタブをいじっていてたまたま気づいたのですが、閉じるボタン上でのマウス中ボタンクリックでは「タブを閉じる」が発動しないようです。おそらく以前からそうだったのだろうと思いますし、今回ようやっと気付いたくらいの軽微さですから、そのうち確認いただければ幸いです。
| yuko | 返信 -
Kuroさん、Ver 3.7.7のリリースお疲れさまでした。
Ver 3.7.7を確認しましたが、[オプション] の [タブ] カテゴリに [ダーティ インジケーターをドットで表示する] オプションが追加されていて、正常に動作することを確認しました。
以前は更新マークが挿入されてタブ幅が変わるので、タブが動くのが気になっていました。
ですが、上記のオプションをONにしてからはタブ幅が変わらなくなったので、タブが動かなくなって見やすくなりました。また、上書き保存をしていないファイルが判別しやすくなりました。
ご対応いただきありがとうございます。
| MSY-07 | 返信 -
>> yuko さん
> ダーティインジケータ対応、ありがとうございました & お疲れ様でした。
早速ご確認いただき、ありがとうございます。
毎度のことながら、リリース直後にバグが見つかる「リリースあるある」が発症しそうで、ちょっとドキドキです。
> 今回のアップデートもなかなか盛り盛りですね。特に、アウトラインプラグインの件はありがとうございます。MarkdownのコメントブロックでShell Script書くのが益々快適になります😊
今回の更新は 30 項目を超えていて、脳が少しオーバーフロー気味ですが…💦
アウトライン プラグインについては、本体側のパーサーを使う方法がうまくいったので、実験的に組み込んでみました。快適に使っていただけると嬉しいです。
> タブ幅が変わらなくなったのはもちろん嬉しいですが、それに加え、更新が掛かっているタブがぱっと見ですぐ分かるようになって、とてもいい感じです。
そうですね。VSCode に慣れている方には、自然に馴染むような変更かなと思います😊
> 閉じるボタン上でのマウス中ボタンクリックでは「タブを閉じる」が発動しないようです。
そう言われてみるとそうですね。ボタン系の UI で中ボタンクリックを想定していなかったので未対応でしたが、VSCode や Edge を見てみると、確かに中ボタンクリックが有効になっていますね。
次のバージョンで対応を検討してみますね。
>> MSY-07 さん
ご確認いただき、ありがとうございます。
> Kuroさん、Ver 3.7.7のリリースお疲れさまでした。
ありがとうございます。Ver 3.7.6 では貴重なフィードバックをいただき、とても助かりました。
> 上記のオプションをONにしてからはタブ幅が変わらなくなったので、タブが動かなくなって見やすくなりました。
うまく動作しているようで安心しました。
> > 以前は更新マークが挿入されてタブ幅が変わるので、タブが動くのが気になっていました。
確か、以前はタブの幅を [指定した幅に固定する] 設定にされていたと思いますが、現在は [ファイル名に合わせる] (または [切り詰める]？) オプションに変更されたのですね。
ちなみに、Ver 3.7.7 では [指定した幅に固定する] 設定でも、タブの文字列がはみ出た際にファイルの拡張子や「*」マークができるだけ表示されるよう調整しています。
[ダーティ インジケータをドットで表示する] オプションがオフの際も、少し使いやすさが向上しているかと思いますので、よければお試しください。
| Kuro | 返信 -
> ありがとうございます。Ver 3.7.6 では貴重なフィードバックをいただき、とても助かりました。
お役に立てたのであれば光栄です😊
> 確か、以前はタブの幅を [指定した幅に固定する] 設定にされていたと思いますが、現在は [ファイル名に合わせる] (または [切り詰める]？) オプションに変更されたのですね。
普段はファイル名が全部見えた方が分かりやすいので、タブの幅を [ファイル名に合わせる] に設定しています。
ですが、大量にファイルを開いたりファイル名が長かったりしてタブが2段以上になるときは、[指定した幅に固定する] または [切り詰める] に変更しています。
> ちなみに、Ver 3.7.7 では [指定した幅に固定する] 設定でも、タブの文字列がはみ出た際にファイルの拡張子や「*」マークができるだけ表示されるよう調整しています。
[指定した幅に固定する] 設定を試してみましたが、タブの文字列がはみ出た際に「*」マークが表示されるようになったので、どのファイルが上書き保存されていないのかが判別しやすくなっていいですね😄
また、拡張子も見えるようになったので、ファイルの種類が判別しやすくなったのもいいですね。
| MSY-07 | 返信
