[ruby-list:41236] Re: [RFC] framework of Ruby/Tk + VNC

永井@知能．九工大です．

From: nakamura <[e-mail]>
Subject: [ruby-list:41226] Re: [RFC] framework of Ruby/Tk + VNC
Date: Sun, 9 Oct 2005 11:21:48 +0900
Message-ID: <[e-mail]>
> > あのデモは，接続後 60 秒で強制切断するように作っています．
> > これが原因で切断された場合は正常な結果です．
> あ。そうだったんですか。
> ＃どっかに書いてあったっけ…(^^;

デモの背景になっているキャンバスウィジェットの上に．(^_^;

> もし画面に出る例外の名称またはMessageを
> 自由に設定できるならば、
> それでもってTimeoutだということを表現(自己主張)すれば
> すぐにピンと来るだろうなとは想いますが、無理かな…

既存の Java 版 VNC クライアントをそのまま使っているので
仕方のない部分ですね．
「クライアントには依存しない」としているので，
強制切断をクライアントがどう扱うか次第となってしまいます．

> 接続を切っちゃうってことは、
> ダイアログ出しても定刻になれば画面はどうせグレー化する
> わけでしょうから、
> ダイアログの内容は「切れました」じゃなく「まもなく切れます」
> とかにせざるを得ない、のでしょうね。でしょうか。

はい，そうなります．

> となると、そのダイアログを見れる期間はせいせい数秒、
> 余所見してて気づかなかったらアウト、ということになっちゃいそう。

画面上のどこかに残り時間のカウンタを出しておいて，
切断する前に確認のダイアログを表示．
確認の OK をクリックしたら即座に切断．
確認の OK をクリックしなくても，そのままにしておいたら
30 〜 60 秒程度で強制切断．
．．．というぐらいならいいですかね？

今回のデモは，サーバの能力が貧弱 (P2-300 MHz, メモリ 128MB) 
であることと，ネットワークへの負担を押さえたいということとで
60 秒で強制切断としましたが，サーバ側からの強制切断が必要ない
ということでしたら，もちろん，そうすることもできます．
今回のデモで言えば，wrap_test_main2.rb の
------------------------------------------------
Tk.after(timeout * 1000){exit}
------------------------------------------------
の行をコメントアウトすればいいだけです．

# これは，公開用スクリプトの実行をマスターが監視できることの
# 例でもあります．
# 安全のために，公開用スクリプトが同時に生成できるトップレベル
# ウィジェットの総数を制限するなども簡単です．

ちなみに Tcl/Tk 8.5 では tk コマンドに inactive という
サブコマンドが新設され，これを使うとユーザが最後に何らかの
操作を行ってから (あるいはスクリプトでリセットしてから) 
何 ms の時間が過ぎたかを調べることができます．
これを使えば「操作がなくなってから 60 秒で切断」とかも
可能になります．
Ruby/Tk では Tk.inactive, Tk.reset_inactive 等で対応済みです．

> まあ細かいことは
> (今の段階では)さておいたほうが
> 良いかも知れませんけど(^^;。

はい．このフレームワークはまだ開発中です．
ユーザの操作によるウィンドウのリサイズやクローズもまだできませんし，
スレーブの wm コマンド関係の置き換えもできていません．
公式に「使える」ものにするには，まだいくつか山を越えねばなりません．
細かいことは，多分，その後ですね．

# Ruby/Tk のサンプルに含まれている TkTextIO クラスを改良しての
# コンソールの代用品なんてものも，ぼちぼちと作成しようとしてます．

> Tk画面をリモートに飛ばせるなら、
> インストールの犠牲(笑)になるマシンは
> 1台で済ませられますもんね。

なるほど．(^_^)
今はサーバを立てるためにちょっとした細工 (現在のサーバでは，
リモートから接続された場合に gdm が 起動する greeter をすり替える
ようにしています) を施す必要がありますが，正式公開の折には
簡単にサーバ立ち上げができるようなツールを提供したいですね．

# ご承知のこととは思いますが，必要であれば RFB プロトコルでの接続と
# 並行してクライアントとの間にもう 1 本の接続を生成するというのも
# 当然可能です．
# これを応用すれば，できることがさらに広がるはずです．

> そういう意味で、期待してます。

ありがとうございます．ぜひ期待に応えられるものにしたいと思います．
-- 
                                       永井 秀利 （九工大 知能情報）
                                           [e-mail]