Linuxへの提案

1.GTK+ Lisp

GTK+Lispインタプリタを搭載し、全てのGTK+アプリケーションの内部をLispで操作出来る「GTK+ Lisp」。
後日注記:GNOMEにはLooking Glassというデバッグシェルがあり、JavaScriptでUI要素を調査したり、コードスニペットを実行できる。

2.ディスプレイ・スクリプト

ディスプレイに表示された内容をスクリプトで操作出来る「ディスプレイ・スクリプト」。

3.ディレクトリ・レイヤー

複数のディレクトリを一つのディレクトリに重ね合わせることの出来る「ディレクトリ・レイヤー」。手動でインストールしたパッケージの管理が楽になる。

4.パッケージ・フィード

アプリケーションの開発プロジェクトが公開した最新のリリース情報をフィードで自動的に知ることの出来る「パッケージ・フィード」。

5.セキュリティ更新プロジェクト

ディストリビューションのセキュリティの更新を専門のセキュリティ更新プロジェクトがやってくれる「セキュリティ更新プロジェクト」。

6.新しいディストリビューションの開発

ディストリビューションのコアの開発を各ディストリビューションが統合・統一してやる「共通コア開発」と、著名パッケージに対して安定板と最新版とライト版を配布する「マルチ・ディストリビュート」、そしてマイナーなパッケージは外部ユーザーが提供する「ユーザー・リポジトリ」によって、ディストリビューションの開発と利用を大幅に簡単にする。

7.実行リスト

最初の起動時に自動で検出・実行した処理を記録し、次からは同じ処理だけをただ実行することで起動を速くする「実行リスト」。

8.システム・ファイルマネージャ・モード

ユーザーのホームディレクトリのような個人的なファイルマネージャの管理機能と、システムのファイルマネージャの機能を分け、別のインターフェースを提供する「システム・ファイルマネージャ・モード」。システムモードでは、システムのコマンドや設定ファイルのマニュアルを表示したり、一行の説明を読めたり、どのパッケージに含まれるかを知ったりすることが出来る。

9.パッケージ・ログ

パッケージマネージャのGUIのログインターフェースを提供する「パッケージ・ログ」。今までインストールした全てのパッケージとアクションを記録し、必要なところまで戻ったり、簡単にアンドゥ・リドゥが出来たり、システムを壊さないように安全かつ簡単にインストールしたパッケージを削除出来る。

10.GUIバックエンド

GNOMEKDEのライブラリをバックエンドにし、バックエンドを切り替えることが出来るようにする「GUIバックエンド」。

11.自然なデスクトップ・インターフェース

GUIのインターフェースを出来るだけ「人間的」かつ「自然」にし、キー入力とマウス操作の手間を出来るだけ少なくし、ユーザーが考えなくてはならない労力を減らす、「自然なデスクトップ・インターフェース」。特に、メニューに操作を、サイドバーに管理を、ボタンに状況別メニューをと言う風に、操作と管理を分けたりするなど、出来るだけ自然に、考えられたインターフェースを提供する。クリックは要素の選択にし、そこから状況別メニューを表示し、それをクリックすることで操作するようにしても良い。GNOMEの問題点は、「自然でないこと」である。デスクトップ環境としてこうあるべきだと言う「自然」な考え方がない。

12.GTK+ Delphi

GTK+のライブラリ関数をDelphiのようなオブジェクト指向にしたラッパーAPIである「GTK+ Delphi」。

13.オープンソース・クラスライブラリ

文字の比較やネットワーク通信などのルーチン的ライブラリや、GUIやWebのフレームワークを統合した、「オープンソース・クラスライブラリ」。

14.ファイルディレクト

ファイルの中にディレクトリを作る「ファイルディレクトリ」。特に、コピーの高速化を目指す。ファイルをコピーする時は、変更された下位ファイルだけをコピーすることで、コピーが高速になる。

15.ツールキットサーバーとTKML

X11サーバーとは別に、今Xlibの単純なライブラリになっているGTK+やQtを分割し、そこもサーバーとクライアントにする。
ツールキットサーバーは標準プロトコルと標準言語(TKML)を裁定し、バックエンドでGTK+やQtを動かす。
どんなアプリケーションを使うのであっても、そのアプリケーションをGTK+でもQtでも表示出来るようになる。
ツールキットクライアントにはTKMLを中心としたC言語の言語非依存のライブラリを作る。それにより、GTK+/GNOMEのようにさまざまな言語でのプログラミングが可能となる。
HTMLを表示するブラウザにFirefoxChromeなどがあるのと同じで、ツールキットサーバーは「UIブラウザ」と呼んでも良い。
TKMLは表示するだけだが、本当はツールキットを操作するオペレーション言語も必要だ。それを、TKOLとしよう。そして、TKMLとTKOLを合わせてTKLとする。これを、SQLのようにプログラマはどこからでもTKLで書かれたアプリケーションをツールキットサーバーに表示できるようになる。
TKMLをHTMLのように、TKOLをJavaScriptのように書いても良いだろう。こんな風にすれば良い:

[button1: (clicked: button1_clicked())]
[button2: (clicked: button2_clicked())]
[text1: (text_changed: text1_changed(text1.getThisEvent()))]

func button1_clicked(void){
  this_button.label = "clicked";
}

func text1_changed(event e){
  text.write("new_key: %c\n", e.getPressedKey());
}

なぜかJavaみたいな言語になった。本当はSQLのようにしたかった。
TKOLをこんな言語にしても良いだろう:

ADD browser1 INTO box1 WHERE 2

これはSQLのような言語だから、TKSLという名前にしよう。