議論/画面出力抽象化/2006


Top / 議論 / 画面出力抽象化 / 2006

このページは何か? (by ひげぽん)

画面のテキスト出力制御を議論します。

ログ

目的

経緯

現状把握と問題点

標準入出力の実装を行っているときに、Shell Serverから表示部分を分離すべきだと考えるようになりました。
議論/画面出力抽象化/2006/01.現状の表示処理を見てもらえば分かりますが、現状では大雑把に

Shell(CUI) -> print/drawCaret -> VESAConsole/Screen -> 出力
Shell(GUI) -> addLine -> BayGUI -> VRAM -> 出力

のような出力フローがあります。
さらに、CUI版とGUI版でロジックの共有化が出来ていないという問題点があります。

考え

出力フローを以下のようにするとうれしいのではないかと考えました。

Shell(CUI/GUI共通) -> なんらかのプロトコル -> 端末(CUI) -> 出力
Shell(CUI/GUI共通) -> なんらかのプロトコル -> 端末(GUI) -> 出力

このようにすれば

調査

上記「なんらかのプロトコル」は、Linuxなどで利用されている端末エミュレーションと関係がありそうなので調べました。
以下のドキュメントを読みました。

僕の浅い理解では以下のようになっているので、今回採用する候補ではないかと思っています。

表示を指示する側エスケープシーケンスつきのテキストデータを出力
端末可能な範囲でエスケープシーケンスに従い出力

迷っていること

画面出力抽象化のインターフェースをどうするか?。
候補は今のところ2つ

上記2点で迷うのは前者に関してあまり詳しくなく「トレンド(かっこ良い悪い)」「規模」「メリット・デメリット」が理解できていないためです。
みなさんの経験と知識を元にアドバイスいただけると助かります。

アクション

  1. ひげぽんが考えていること・迷っていることを整理する
  2. 意見をいただく←いまここ
  3. 最小実装を見極める
  4. 実装する

コメント

最新の1000件を表示しています。 コメントページを参照

お名前:
  • Gakuさんに自分の聞きたかったことを完全に理解してもらえた。僕も昨日いろいろ話を聞いたり調べた感じで「(1)文字列中に制御コードを混ぜて送信する方法」を採用するのが良いのではないかと考えました。のでちとまとめてからすぐに実装してみます。 -- ひげぽん 2006-10-25 (水) 20:42:55
    • 議論/画面出力抽象化/02.制御コード -- ひげぽん 2006-10-25 (水) 21:38:23
  • 質問です。やりたい事はなんでしょうか?やりたい事が「CUI/GUIでShellの処理の共有」であれば、エスケープシーケンスや端末エミュレーションは話が飛んでいるように見えます。エスケープシーケンスを導入したいのならやりたい事がもう少し別なものになるのかなぁと思ったわけです。「表示したいものを端末に渡してあとは任せる」の方がイマイチ分かってないのかな?やりたい事をもう1度書き出してもらうと良いかなぁとか思いました。 -- Gaku 2006-10-25 (水) 00:21:03
    • 今まで printf とかでいい加減にやっていた画面への出力を抽象化する。そしてインターフェースを切って画面表示機能をShellから切り離すことがやりたいことです。>Gakuさん -- ひげぽん 2006-10-25 (水) 00:23:47
    • てことは \b 送ったらバックスペースしたりってことかな。「CUI/GUIでShellの処理の共有」が目的なら必要最低限作るのが良いように思います。エスケープシーケンスだとか端末エミュレータが目的ならしっかり作った方が良いのじゃないかな。で、多分、前者で済ます方が良いと思うに1票かな。 -- Gaku 2006-10-25 (水) 00:32:43
      • (理由:目的が「CUI/GUIでShellの処理の共有」のように見受けられる。エスケープシーケンス対応したい。て目的になっていないように見える。) -- Gaku 2006-10-25 (水) 00:36:11
      • (と。エスケープシーケンスの受け取り方に差が出るかな。エスケープシーケンスっていうと、出力文字の色が指定できたり、カーソル移動ができたり、カーソルから何行上だか下だかの行を削除できたり、カーソルの表示・非表示ができたり、とか色々な機能を含んだセット。というイメージですね。) -- Gaku 2006-10-25 (水) 00:52:00
      • 共有が第一目的ではないですね。あくまでも出力を抽象化する。ってのが第一目的です。 -- ひげぽん 2006-10-25 (水) 00:54:23
    • おや。「出力の抽象化」が目的ですか。そしたら、どこまで抽象化するのか?が気になるかな?抽象化したい出力のユースケースとか幾つか上げられます? -- Gaku 2006-10-25 (水) 01:03:26
      • (「出力の抽象化」は目的なのかな?文字出力を共通の方法でやりたい。とか、文字をカラー出力するのを共通の方法でやりたい。とかが目的なのじゃないかな?そうしたら、目的が分かれば、おのずと、どこまでのセットを作り込むべきか見えるはず。。。じゃないかなぁと思うので聞いてみてる訳です。) -- Gaku 2006-10-25 (水) 01:08:32
      • 待てよ。やりたい事は分かってますね。『「カーソル位置設定」+「caretの描画」+「テキスト出力」』ですね。 -- Gaku 2006-10-25 (水) 01:25:44
    • てことは『「カーソル位置設定」+「caretの描画」+「テキスト出力」』あたりを作るのに、(1)文字列中に制御コードを混ぜて送信する方法、(2)メッセージかAPIを用意して送る方法、のどっちが良いか。という単純な2択なのか。 -- Gaku 2006-10-25 (水) 01:28:57
      • してみるに、エスケープシーケンスみたいな画面制御方法に対応するのに、(1)ならそのまま拡張すれば良い、(2)なら別途それ用のライブラリを用意して端末を使う側でそれを使ってやる必要がある。てな話が出てくるわけですね。とやっと追いついたかも。 -- Gaku 2006-10-25 (水) 01:32:14
      • んー。Monaは別段、エスケープシーケンス使ってる遺産が貯まってるわけでもないですし。どちらでも良いかな?(今(2)で作ってしまったとして、後でエスケープシーケンス使う何かを移植したくなったとしても、そのときに端末との間にエスケープシーケンス解釈用の何かをはさんで対応できるでしょうし) -- Gaku 2006-10-25 (水) 01:34:38
      • 後は、(1)なら必要セットが見えている。(2)は見えていないので、自分が必要なものから作る→後々変更しまくる。拡張のみで変更がしばらくないだろう確率が高そうなので(1)が安心、(2)は不安、とかあるかな? -- Gaku 2006-10-25 (水) 01:41:20
  • 候補前者のメリットは大きいと思います。既存の環境やアプリとの相性が抜群に良いですよね。例えば、telnetしてviするとか、nethack(古っ)とか。 -- h? 2006-10-24 (火) 20:41:05
    • メリットが大きいのはその通りですね。ただ実装コストとのバランスが難しいですね。他の人の意見もききたいところ。 -- ひげぽん 2006-10-24 (火) 22:05:18

MENU

now: 3

リンク


最新の20件
2017-09-29 2017-04-25 2017-01-10 2016-12-11 2016-12-09 2016-10-04 2016-08-14 2016-06-05 2016-05-29 2016-04-15 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 2975, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:03 (3681d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.131 sec.