tanasinn terminal emulator

Controlキーの2度押し (ctrl + ctrl) でコマンドラインランチャーインターフェースが出現します。
そこで例えば、"man man[Enterキー]" とタイプしてみてください。
ウィンドウのようなUIがブラウザウィンドウ内に現れ、manページが表示されると思います。

アドオン版と同様、Controlキーの2度押し (ctrl + ctrl) でtanasinnが起動します。
Vimperator/Muttatorのコマンドライン上から起動したい場合は、以下のようにタイプしてください。

もしターミナルスクリーンをVimperator/Muttatorから直接起動させたければ、以下のようにします:

tanasinnにコマンドを送信したいときは、以下のようにします:

tanasinnにキー入力を送信したいときは、以下のようにします:

このチュートリアルでは、簡単なtanasinnプラグインの作成過程を、なるべく平易な形で説明していきたいと思います。
初級編なので、「覚えることを最小限に」をモットーとしたいと思います。
拡張モジュールを書くためにtanasinnコアのソースをいきなり読みはじめるのはおすすめしません。
読むと精神的にやられます。
あのような書き方をせずとも、実はそこそこクリーンなJavascriptコードでプラグインを記述することができます。
記述は少し冗長になりますが総合的にみてずっと生産的です。
本チュートリアルではクリーンで単純なサンプル提示を心掛けます。

チュートリアルに入る前に、これだけはどうしても触れておかなければなりません。「イベントバス」です。
「覚えることを最小限に」をふまえたうえでも、この説明だけはちょっとはずせません。
tanasinnは結合度的にかなりゆるいタイプのコンポーネントフレームワークを基盤として
構築されており、コンポーネント間のコミュニケーションは基本、同期的なメッセージ指向です。
そのメッセージ(セマンティクス上はイベントだったりコマンドだったりget関数だったりする)は、下図に示されるような
階層化されたバス上を流れています。

階層的に構築されたLANのようなものをイメージしてもらえるといいと思います。
ソフトウェアパターン的には、Observerパターンを階層化したもの、ととらえるとわかりやすいかなと思います。
このような階層において子要素を持つもの、上図においては、Process、Desktop、Sessionのようなものが、イベントを管理しています。
tanasinnハッカー達はこれを「イベントブローカー」、あるいは単に「ブローカー」と呼んでいます。
また逆にこの親要素にぶらさがっているもの、上図においてはProcess以外のノードを、「コンポーネント」と呼んでいます。
たとえば上の図でいうと、DesktopとSessionはイベントブローカー兼コンポーネントということになります。
コンポーネント「tty」はSessionというイベントブローカーを介してコンポーネント「screen」にメッセージを送ったりできるわけです。
イベントはUIウィジェットにおけるそれのようにキャプチャリングされたり、バブリングしたりすることはなく、
必要なら明示的にルーティングしてやる必要があります。
またVimperator/KeySnail使い的にはやや戸惑うかと思われますが、ブローカーはその子供(コンポーネント)に対する参照をもちません。
たとえばSessionというオブジェクトから「tty」への参照を明示的にひっぱってくることができません。
ややめんどくさいですがtanasinn全体がこのようなルールで構築されています。

まず、お使いのFirefox/Thunderbird/SeaMonkey等にtanasinnを導入してください。
以下の説明はtanasinn 0.1.5.4以上の環境を想定しているので、tanasinnは最新版を入れておいてください。
$HOME/.tanasinnがすでにある場合、以降の説明がtanasinnの実際の動きと食い違うことがあるかもしれませんので、
リネーム等しておくと、はまらなくてよいです。

これを、
%USERPROFILE%¥.tanasinn¥modules¥session_components¥ (Windows)
$HOME/.tanasinn/modules/session_components/ (Mac/Linux/FreeBSD)
につっこみます。フォルダ(ディレクトリ)は無いと思うので作成してください。

この状態でターミナルセッションを開始してみます。
こうなります。

ここでもし余裕があればalert関数の中身を変えるなどして、いろいろ実験してみてください。
聡明な方なら以下のことがわかると思います。

今度はセッションバス上を飛び交うメッセージを補足し、他のプラグインとコミュニケートしてみます。簡単です。

下図のように、キーボードを押すたびにオーバーレイインジケータが出てくると思います。

これは、「input」というコンポーネントからメッセージを受けとり、プラグイン「Overlay Indicator」にデータを
渡しています。"event/before-input" や "command/report-overlay-message" はイベントソースを識別するた
めの文字列で、「トピック」と呼ばれています。

つぎのサンプルにとりかかる前に、デバッグ環境を補強しましょう。
コンソールを有効化します。

なにかキーボードを押して"event/before-input"イベントを発生させるたびに、エラーが補足されます。
こうなります。

例外が自動補足されるということは、例外がコンポーネント境界を超えて伝播されないということでもあり
(実際は伝播させる方法もありますが)、tanasinnは基本、エラーに対してとてもルーズな
立場をとります。こまめにコンソールをチェックして対処するというケースが多いです。
テスト機構が完成すれば事情はもうちょっとましになりますが。
さきほどconsoleを有効化しましたが、通常使用時にはパフォーマンスを下げるので無効化しておいたほうが良いです。
consoleがなくても、ランタイムディレクトリ以下のlog/tanasinn-js.logを見ればエラー等を診断できます。

コンポーネントを作成しましょう。
コンポーネントはプラグインの一歩手前の、プラグアンドプレイをサポートしない原始的なオブジェクトです。
tanasinnの規約によるとコンポーネントの最小要件は、以下のとおりです。

.英数字及びアンダースコア(_)、ハイフン(-)、ドット(.)の組み合せで表現されるString型のidをもつ。
.メッセージ "get/components" に対して、自分自身を返す。

コードで表現してみましょう。

コンポーネントの登録に相当する部分です。
登録というよりも、コンポーネントいるかーとか、メニューアイテムいるかーとか、バスに対して訊いてみて、
だれかが反応するような感じです。tanasinnではだいたいの事柄がそんなふうに表現されています。ほとんどがメッセージです。
ただし、idやenabledというシグネチャ等を要求することもあるので部分的にインターフェース指向でもあります。

今回のサンプルは他のコンポーネントとおしゃべりするための準備だったのですが、このままだと達成感ゼロなので、
最新ビルドにはlscomponentというコマンドを入れておきました。
何もしないコマンドなのですが、補完でコンポーネントを列挙します。
これです。

今回作成したsampleが、ちゃんとコンポーネントとして認識されています。
軽く100を超えるコンポーネントからtanasinnが構成されていることがわかりますね。

----- つづく。

In this event system, registered events is concerned by "topic" that
is string variable consists of some digits and alphabets.

If you registered an event as follows:

var id = broker.subscribe(<topic>, <handler>, ....);

This event handler could be fired as following code:

broker.notify(<topic>);

The subscribe method returns an ID string.
When you want to unregister handler, use it as follows:

broker.unsubscribe(id);

NOTE that this ID is NOT corresponds to a handler, one-to-one.
The relation between Topic-ID is as same as that, because this event
system is based on the concept of multicast delegate system.

Event Expression indicates how the broker waits multiple events.
It was given to subscriber method, that called such as:

broker.subscribe(<expression>, ....);

<expression> consists of 1 or multiple event topics and other tokens,
that ruled by simple grammar. the detail of it is as below...

-> it triggered when the event "A" is signaled.

-> wait for multiple events "A" OR "B".
   it is triggered when one of either events is signaled.

-> wait for both events "A" AND "B"
   it is triggered when both of these events is signaled.

<startcommand> is asked for tanasinn through the <Control channel>.

figure-1. Communication among TTY device pair, TeletypeDriver, tanasinn.

UI-template is JSON-style object that is described as based on the
specific rule.
It is to be converted to a node set of XUL/HTML/SVG elements by
"Template Builder" object.
Dependencies between DOM fragments are automatically resolved.
You need not to take care of order for building them.

It will be converted to following XUL element.

Every UI-template object consists of <Element node> (1), and it is
typically a tree set of <Element node>s.
It always includes "tagName" property (2), and often includes
<Style node> (3).
<Style node> may have some CSS properties in camel-case (4).

It will be converted as below.

The "parentNode" property (5) indicates at which the current node is to
be set. if the type of property value was "string", it regards as node
ID of the parent node. or if its type is "object", especially
HTMLElement, it regards as the parent node object itself.
The "childNodes" property has an effect which cascades down
following <Element node> (6). If you wanted to create two or more
child nodes under the same node, you should substitute an Array of
<Element node>s (7) in "childNodes" property.
The "innerText" property (8) creates a text node under current
<Element node>.

It almost corresponds to following XUL code.

The "onconstruct" property (9) defines a event function which fired
when the property itself is parsed.
The "listener" property (10) attaches a event handler at the current
<Element node>.