UNIXやLinuxのシステム管理（システム・コマンド・設定）に関する世界観９（提案）です。
Linuxに追加する機能の提案。
GTK+にLispインタプリタを搭載し、全てのGTK+アプリケーションの内部をLispで操作出来る「GTK+ Lisp」。
後日注記：GNOMEにはLooking Glassというデバッグシェルがあり、JavaScriptでUI要素を調査したり、コードスニペットを実行できる。
LispやGTK言語バインディングやGNOMEデスクトップやEmacsも参照のこと。
ディスプレイに表示された内容をスクリプトで操作出来る「ディスプレイ・スクリプト」。
複数のディレクトリを一つのディレクトリに重ね合わせることの出来る「ディレクトリ・レイヤー」。
手動でインストールしたパッケージの管理が楽になる。
ソースからのインストールも参照のこと。
アプリケーションの開発プロジェクトが公開した最新のリリース情報をフィードで自動的に知ることの出来る「パッケージ・フィード」。
パッケージ管理も参照のこと。
各ディストリビューションのセキュリティの更新を専門のセキュリティ更新プロジェクトがやってくれる「セキュリティ更新プロジェクト」。
セキュリティも参照のこと。
ディストリビューションのコアの開発を各ディストリビューションが統合・統一してやる「共通コア開発」と、著名パッケージに対して安定板と最新版とライト版を配布する「マルチ・ディストリビュート」、そしてマイナーなパッケージは外部ユーザーが提供する「ユーザー・リポジトリ」によって、ディストリビューションの開発と利用を大幅に簡単にする。
Linuxディストリビューションも参照のこと。
最初の起動時に自動で検出・実行した処理を記録し、次からは同じ処理だけをただ実行することで起動を速くする「実行リスト」。
ユーザーのホームディレクトリのような個人的なファイルマネージャの管理機能と、システムのファイルマネージャの機能を分け、別のインターフェースを提供する「システム・ファイルマネージャ・モード」。
システムモードでは、システムのコマンドや設定ファイルのマニュアルを表示したり、一行の説明を読めたり、どのパッケージに含まれるかを知ったりすることが出来る。
パッケージマネージャのGUIのログインターフェースを提供する「パッケージ・ログ」。
今までインストールした全てのパッケージとアクションを記録し、必要なところまで戻ったり、簡単にアンドゥ・リドゥが出来たり、システムを壊さないように安全かつ簡単にインストールしたパッケージを削除出来る。
GNOMEとKDEのライブラリをバックエンドにし、バックエンドを切り替えることが出来るようにする「GUIバックエンド」。
GUIのインターフェースを出来るだけ「人間的」かつ「自然」にし、キー入力とマウス操作の手間を出来るだけ少なくし、ユーザーが考えなくてはならない労力を減らす、「自然なデスクトップ・インターフェース」。
特に、メニューに操作を、サイドバーに管理を、ボタンに状況別メニューをと言う風に、操作と管理を分けたりするなど、出来るだけ自然に、考えられたインターフェースを提供する。
クリックは要素の選択にし、そこから状況別メニューを表示し、それをクリックすることで操作するようにしても良い。
GNOMEの問題点は、「自然でないこと」である。デスクトップ環境としてこうあるべきだと言う「自然」な考え方がない。
X11も参照のこと。
GTK+のライブラリ関数をDelphiのようなオブジェクト指向にしたラッパーAPIである「GTK+ Delphi」。
Delphiも参照のこと。
文字の比較やネットワーク通信などのルーチン的ライブラリや、GUIやWebのフレームワークを統合した、「オープンソース・クラスライブラリ」。
ファイルの中にディレクトリを作る「ファイルディレクトリ」。
特に、コピーの高速化を目指す。
ファイルをコピーする時は、変更された下位ファイルだけをコピーすることで、コピーが高速になる。
X11サーバーとは別に、今Xlibの単純なライブラリになっているGTK+やQtを分割し、そこもサーバーとクライアントにする。
ツールキットサーバーは標準プロトコルと標準言語（TKML）を裁定し、バックエンドでGTK+やQtを動かす。
どんなアプリケーションを使うのであっても、そのアプリケーションをGTK+でもQtでも表示出来るようになる。
ツールキットクライアントにはTKMLを中心としたC言語の言語非依存のライブラリを作る。それにより、GTK+/GNOMEのようにさまざまな言語でのプログラミングが可能となる。
HTMLを表示するブラウザにFirefoxやChromeなどがあるのと同じで、ツールキットサーバーは「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という名前にしよう。
2018-01-31に関連する内容があります。
この他にもさまざまな提案を日記でしています。ぜひ日記もご覧ください！