TEKの設定UI

[nmaya]

Window 設定

• 1 どちらでもつかうのでどちらにも表示
  • Title
  • HideTitle
  • BGNoFrame
  • PopupMenu―Hide menu bar and enable popup menu
• 2 VT専用
  • PcBoldColor―16 Colors (PC style)
  • Aixterm16Color
  • Xterm256Color
  • EnableBold―※1 太く表示するかどうか
  • 文字色
    • VTColor
    • VTBoldColor
    • VTBlinkColor
    • VTReverseColor
    • URLColor
    • VTUnderlineColor
    • UseNormalBGColor
• 3 TEK 専用
  • TEKColorEmulation―TEKでは"Color emulation"だが、ダイアログを共用しているので"16 Color (PC style)"と出ている―細かいバグ
  • 文字色
    • TEKColor

参考: Visual タブにある設定

• EnableBoldAttrColor
• EnableBold―※1 上と同じ
• UnderlineAttrColor
• UnderlineAttrFont―Underline属性の文字にアンダーラインを表示するか―色だけ反映ということができるために
• EnableBlinkAttrColor
• EnableReverseAttrColor
• EnableURLColor
• URLUnderline―URLにアンダーラインを表示するか
• EnableANSIColor

Font 設定

• VTFont
• TEKFont

[nmaya]

Window 設定ですが、いままで VT/TEK から同じダイアログを呼んで、呼び元により項目が切り替わっていました。
以前は単体のダイアログだったので「いまはVTの設定/いまはTEKの設定」と頭のなかでわかりましたが、タブを切り替える今のUIでは切り替えればほかの設定もあるダイアログなので、この挙動は不自然なように思います。
移植が落ち着いて、全体の項目整理をするときにまた考えませんか？

Originally posted by @nmaya in #84 (comment)

[nmaya]

TEK window の Setup > Font も 従来ダイアログが残っていますし、
TEK window の Setup > 配下には Window と Font しかありませんので、
この２つは従来方式のダイアログが残っている、という形であればユーザにとってもわかりやすいと思います。

ついては、いったん以下のような整理にしておく案はどうでしょうか。

• VT window の Setup > Window... は、Additional settings の Window タブに行く。
  • Additional settings の Window タブは VT window の設定専用として、TEK window の設定には関与しない。
• TEK window の Setup > Window は、従来の Window setup ダイアログを出す。

Originally posted by @sempreff in #84 (comment)

[nmaya]

@zmatsuo

• sempreff さんの案
• いまの実装
• ここから改良

どうするのがよいでしょうか？

Originally posted by @nmaya in #84 (comment)

[nmaya]

使っている人からみると
「VTWindow 用の Windowタブ」と
「TEKWindow 用の Windowタブ」はとても似ているけど別タブで、
VTWindowから設定する時は、VTWindow用が出ていて、TEKWindow用は出ていない。
TEKWindowから設定する時は、TEKWindow用が出ていて、VTWindow用は出ていない。
という風に見えるのかな?

いつもVT/TEKWindow用の両方のタブを出すのも分かりやすいかもしれません。
(両方のタブに同一の設定項目が出ているならその設定項目は要調整です)

でも、TEKWindowはあまり使われない感じがするので出すと邪魔と思う人もいるかも。
TEKWindowが出ているときには、TEKWindow用タブも出てくるのもありでしょうか。

必要なタブだけを出す方針だと現在の状態でよさそうです。
タブが1個だけというは、概ねsempreff さんの案と同じかなと思います。

色が反映されないバグが直っているので
fbf9a38 をいったんmainにマージしようと思います。

Originally posted by @zmatsuo in #84 (comment)

[nmaya]

状態によってタブや項目が出たり出なかったりするのはよくありません。
ユーザが設定の位置を見つけ（覚え）づらくなります。

その基準で考えると

呼び出し元によって変わる今の実装
TEKWindowが出ているときには、TEKWindow用タブも出てくる

はなく、

いつもVT/TEKWindow用の両方のタブを出すのも分かりやすいかもしれません。

これか

sempreff さんの「WindowダイアログをTEK専用にする」（5.3の挙動）「TEKFontは今までのまま」（5.3の挙動）

これのどちらかになります。
sempreff さんの「いったん」は「#84 の作業をしている間は」でしょうか？

私は最終的に「いつもVT/TEKWindow用の両方のタブを出す」がよいと思います。

[nmaya]

いつもVT/TEKWindow用の両方のタブを出すのも分かりやすいかもしれません。
(両方のタブに同一の設定項目が出ているならその設定項目は要調整です)

これはそのとおりで、上に書いたようになります。

• 両方にある設定項目をどうするか
• Window ダイアログに文字色があるか、Visualタブには文字属性の設定がある。これをどう整理するか
• TEKFont をどうするか

など、TEK だけでなく #84 の大元の「項目の整理」の範疇になっていくと思います。

[sempreff]

交通整理ありがとうございます。

「いったん」は「#84 の作業をしている間は」でしょうか？

「仕上がりイメージが決まるまでは」という感じです。。

今は、あちこちで 影響範囲を把握しないまま 優先順位を整理しないまま 改造が進められていて、副作用による混乱が さまざまなところで 起きている状態 だと思っています。

本件を例にとると、「TEK の Setup > Window はこうしよう」「TEK の Setup > Font はこうしよう」という方針が無いまま作業だけを進めることは、#84 で解決したい課題であるところの「混迷を極めている」状況に さらに拍車がかかることに繋がってしまいます。

また main ブランチが unstable すぎたり 未確定の内容が混入したりすると #84 以外の修正に影響したり、リリース版が不安定になるリスクすらあるので、落ち着いて進めてほしいです。

そのためには、予期せぬ副作用や従来機能の損失などの不具合が見つかった時には それまでの作業を既成事実化してそのまま進めるのではなく、「いったん」分岐点まで戻って進行方向を吟味するのが良いと思う次第です。

[sempreff]

でも、TEKWindowはあまり使われない感じがする

この引用部分に関しては同感です。

また、「TEK の Setup > Window は Additional Settingsが出る」が、「TEK の Setup > Font は独自ダイアログが出る」というのは あまり良い UI とは感じません。タブの有無が動的に切り替わるのは良くないと思いますし、Addition Settings にはその他に膨大な設定項目があって、TEK window と関係ない項目に目移りしてしまうと思うからです。

ですので、私は「TEK の Setup > Window」と「TEK の Setup > Font」は Additional Settings に無理に統合せず、従来ダイアログを用いて設定できれば良い（必要充分）と思います。

ただしもちろん、従来の設定方式に捕われずに VT/TEK window の設定項目をうまく整理できるのであれば、今からそれに反対しようというものではありません。「うまく」とは、理論的に正しいことも大事とは思いますが、ユーザにとって驚き最小の原則でデザインしていただけると良いと思います。

[zmatsuo]

3e9a7a1 のバイナリをビルドしました。

https://ci.appveyor.com/project/teraterm/github-snapshot/builds/50697495/artifacts

TEKWindowの設定-フォントがフォントダイアログではなく
ウィンドウ設定がでてしまっています。
明日修正します。

[zmatsuo]

修正しました。

9acb054 をビルドしました。
https://ci.appveyor.com/project/teraterm/github-snapshot/builds/50703443/artifacts

[nmaya]

副作用による混乱

このご指摘は「プロジェクトの進め方」という別件で、別に話すべきことかもしれませんが、関係する要素だけ手短に上げておきます。

• 設定ダイアログと設定項目の再編成 #84 は大きな修正である
• プロジェクトのコミットルールの「不完全な状態でマージしない」（SVN時代から改稿していない部分だが）は守られていない
  • 大きな修正ゆえかもしれない
• 修正作業は主に @zmatsuo さんが一人でやっている（ほかに大きな作業キャパがある人がいない）
  • いいことではないが、逆にソースレベルの conflict は起きづらい。それぞれ修正を進めてしまうと conflict しそう
  • 多角的な判断は必要
• 「リリースしないとユーザは手を出さずバグも見つからない」という現実
• 別の stable ブランチを作ることについては、SVN で trunk と 4-stable のときには両方の修正を管理するキャパがなかった

[zmatsuo]

混乱を起こすつもりでソースを改造しているないのですが、
ご迷惑をおかけして申し訳ありません。

納得して使える、バグがないのがすぐにほしいという
要求はあると思うのですが
少しずつしか進められません。
努力はしていますが修正の副作用を
100%完璧に見極めることもできていません。

優先順位は各々思うところを進めている感じです。

#84 に関連するところでは、設定ダイアログをタブへ移植することを進めていて
5.3のリリースでは全てを移植するところまですすめられませんでした。
簡単そうなタブから進めていって、
一番難しそうなシリアルポートを残している
TEKの設定にも影響があるのがわかったというのが現状です。

問題が出たらすぐに直してくれそうという
信頼感がまだまだないのかなと思います。
一緒に直して改良してくれる仲間が増えればいいなと思っています。

タブの修正は広範囲にドキュメントの修正が発生しがちです。
さっさとmainにマージしておかないと
他の修正とコンフリクトがおきてしんどいことになりそう、
とついつい思ってしまいます。

TEKの設定ですが、今の main 状態で
従来と同じように設定は可能ではないかと思います。
現状でおいといて、#84 (シリアルタブ)のほうを進めようと思います。

[zmatsuo]

「リリースしないとユーザは手を出さずバグも見つからない」という現実

dev版が存在していることが分かればバグが直っているのを利用したり、
最新版をテストしてもらえるかも。

• dev版(mainをビルドしたバイナリ, AppVeyorのgithub-main)へのリンクをUrlsページに貼る
• ビルドが終わったら、どこかにその情報が発信される
  • XのTeraTerm Project Activitesにつぶやくようにする(できる?)
  • Discordに通知(見ている人とても少ない…)

できると嬉しいオプション

• ビルドの最後でteraterm_version.jsonが自動で生成され、どこかに置かれる
• checkupdateプラグインが保守されて、jsonをチェックできるようにする