ANSIColor[] 1-7, 9-15 の入れ替え処理の変更
私の考えですが、
と、どっちつかずです。
入れ替えるとしても対象は5からとするか、4.107も変えるのかというのも有ります。
このプラグインでは ts.ANSIColor[] を直接編集しているようですね。
TERATERM.INI <-> ts.ANSIColor[] <-(変換1)-> ANSIColor2[] -(変換2)-> 端末表示 ^ ^ ^ | | +----------------> 設定UI | +------------------> カラーパレット変更/カラーパレット設定取得シーケンス +----------> プラグインからのアクセス 変換1: 1-7/9-15 変換2: PC-Style bold/blink
こんなふうに ts.ANSIColor[] はそのままに、変換済みを格納する ANSIColor2[] を持つようにしたら互換性は取れるのでしょうか?
プラグインから変更したあとに、どうにかして ts.ANSIColor[] から ANSIColor2[] への変換を叩かないと反映されないのでしょうけど。
内部256色化の実装で考えていたのはつぎのようなものです。
とりあえず、ts.ANSIColor[16]は従来のまま変更しないでおきます。
vtdisp.c内のANSIColor[256]の最初の16色を 暗い色8色,明るい原色8色に変更します。 描画アトリビュート設定(DispSetupDC())のインデックスの入れ替えがすっきりすると思います。
vtdisp.c内のANSIColor[256]はstaticで、描画などもvtdisp.c内で閉じています。
ts.ANSIColor[16] <-> ANSIColor[256] の部分(vtdisp.cに入るときと出るとき)で気を付ければokなはずです。
テーマの色はts.ANSIColor[16]は(デフォルト色)として、テーマからは影響しないようにして vtdisp.cのANSIColor[256]の最初の16色に作用するようにしてはどうかなと考えていました。 今の実装もそんな気持ちになっています。
もう一つ、描画時にディザリングさせないために GetNearestColor() で存在する色に変換する部分がありますが、 これもvtdisp.cに色を設定するところでやる(か、とにかくvtdisp.c内に閉じ込める)のが妥当だと思っています。
本当はディスプレイが入れ替わるごとにやるのが妥当だと思うのですが、今だとたいていフルカラー出ますし、きにしなくてもよい、GetNearestColor()しなくてもよいかな。
簡単な図にしてみました。
+------------+ +----------+ +----------+ +---------+ |TERATERM.INI| read | ts | |Draw Text | |Theme | | | (Startup)| | | vtdisp.c | launch |Editor | | +--------->+ +---->+ +------->+ | | | | ANSI16 | | ANSI256 | | | | +<---------+ | | +<-------+ | | | Write | | | | OK | | | | | | | | | | +------------+ +----------+ +-----+----+ +--+---+--+ ^ | ^ | Load Save | | Load | (Startup) v | +-----+----------------+---+-------+ | themefile.cpp | +-----+----------------+---+-------+ ^ | ^ | v | | +---+---+--+ | |Theme File| | | INI | +------------+ | | Colors | | | | | | | +----------+ Default theme Solarized theme Tronesque theme :カラーテーマiniファイルの仕様がいくつかあってもthemefile.cpp(r10256 で themefile.cpp,h にそこそこ分離しました)で うまく互換性を持たせるようにできればいくつかのiniファイルがつかえると思っています。
dodaさんのカラーテーマプラグインのiniファイルはもうソースツリーに入れていて(release/theme/color/)、theme editorで一応読めています。
ANSIColorの16色の並びの件をうけて カラーテーマiniファイルの仕様は、
ANSIColor= 1,1, R,G,B, R,G,B ...という仕様よりも
Red=R,G,B Greend=R,G,B Yello=R,G,B DarkRed=R,G,Bという仕様のほうが間違えなくてよさそうだな、というのが今の感触で、iniファイルの仕様を決めないとな、という状態です。
INIファイルからの読み込み/書き込み時に行う、256色をベースにする
まずは、描画部分を256色ベースにするのに着手してみます。
描画部分(vtdisp.c) 内の ANSIColor[] を ANSI256色ベースに変更しました。r10274です。
修正していてこんな風にするほうがよさそうな気がしました。
もう少し考える&後回しです。
r10273でテストがうまくできていなかったので修正しました。
doda への返信
* Tera Termの開発者としては、いくつかのバグの原因にもなっているので読み込み時に入れ替えるようにしたい
* TTXの開発者としては、安易に互換性を失うような変更は入れて欲しくない。実際に影響を受けるTTXも作成している
現状の trunk は、互換性を失っていますか?
ソースの修正方針は
- 4-stableは最小の修正
ticket #45625 を4-stableにいれるのか?については 対応しない、で進めるのはどうでしょうか。
とありますが、これでよいでしょうか?
#45483 からの発展
zmatsuo のコメント
ANSIColor[] の参照入れ替え処理を描画時に行うのではなく、 INIファイルからの読み込み/書き込み時に行う、256色をベースにするのが 良いのではないかと思いつきました。
doda のコメント
読み込みの時点で入れ換えた方が、
辺りから良い影響は多いと思います。
ただ、入れ換えてしまうとANSIカラー設定を参照/操作するTTXで互換性の問題が発生します。
これに関しては別チケットにして検討した方がいいかも。
nmaya のコメント
現状はこうでしょうか。
改善案はこういう感じですか?よいと思います。
このへんは制限事項になりますが、仕方ないですね。