Assyのリベラル文学研究所もご覧ください。

LinuxのGUIについて

X11ソースコード

X11ソースコードは以下から参照できる。カーネルと併せてコードを見ることで、実際のところどんなプログラムが低レベルな領域で動いているのかを確認できる。GTK/GNOMEやQt/KDEの開発がしたい時も、ウィンドウシステムのコードを知ることで、実際にどんなことがデスクトップ環境で行われているのか、全貌を概観できる。

Linuxは単なる機械システムではなく、環境である

2017-10-28より。
Linuxは、機械システムであると同時に、環境でもある。
今のLinuxGUIは、全体が調和されて設計されておらず、非常に完成度が低い印象を与えてしまう。
環境である以上、パクリをせず、全体の信頼性や分かりやすさを大切にしなければならない。
逆にGNOME 3は方向性としては正しい。

SVGとHTMLを拡張して異次元のテーマを

2017-11-01より。
僕は、LinuxGUI環境は、SVGとHTMLの拡張のような言語を作って、どんなグラフィックスでもテーマで描画出来るような、そういう「異次元のテーマ」をサポートするのが良いと思う。
AdobeFlashと似ている。
アイコンは今はpngのようになっているが、どんな風にリストするのか、のようなことまでSVG-HTMLでサポートする。
そういう風にすれば、きっとデザイナーもIllustratorのような雰囲気でLinuxのテーマを作ることが出来るだろう。
出来れば、MicrosoftWindows XPの時に裏で実装していたスキン機能や、XULなどの技術を凌ぐものになってほしい。
UIをXMLにすることで、全てのインターフェースをサポート出来るかもしれない。
だが、GTK+アプリのそれぞれの作り方と矛盾するものになってはいけない。
ある意味、SVGでHTMLにするなら、バックエンドをPHPのようなものにして、そのインタプリタ・エンジンから作っても良い。
ある意味、ブログに良くあるテーマ機能と同じものを作れば良い。
だが、GUIである以上、ページよりもインタラクティブなスキン・シェルにする必要がある。

Linuxを使いやすいものにするために

Linuxを使いやすいものにするために必要なのは、僕が思うに以下のような方針を決めることだと思う。
1.最初から全部の情報を見せて、最も少ない手順で操作出来るようにすること
2.画面上の混乱や変化を最低限にし、驚きの少ない自然な操作を可能にすること
3.何がどの機能、どのアプリケーションを意味しているのかを明確にすること
4.きちんと美しく整理・統合されたものにすること
5.アクションに応じて出てくるメニューなどは、絶対に「自然」の範囲をはみ出さないようにすること
6.分からなくなった時は、何をすればヘルプや解説を得られるのかを明確にし、出来るだけ最初から解説を表示するようにすること
7.ヘビーユーザーのために、たくさんの操作法を可能にすると同時に、画面を整理し、初心者に必要のないインターフェースを初心者が見なくても良いようにすると同時に、どこを操作すればそうした画面の設定を変えられるのか、というボタンを一番目立たせること
8.デザインの基本と同じように、目立たせるべきものと目立たなくて良いものの優先順位をきちんと決めて、その上で良く整理され、統合されたインターフェースをすること
悪い例は、Microsoft OfficeGIMPのようなどこに何があるのかさっぱり分からないアプリケーションで、良い例はEclipseAdobe Illustratorのような考え抜かれたアプリケーションだ。
僕は、昔から「自然」という発想によるインターフェースを良く考える。自然に機能が配置・準備され、自然な挙動を示し、それが自然にそうデザインされるべきである、といった「自然なGUI」というものを考える。そこでは、全てのことに根拠を求めて、どんなところにどんな機能があるのか、デザイナーのようにきちんと考える。ただの機械ではなく、操作環境なのだということを意識する。
今のGNOMEは、リーナス・トーバルズが言っているように、「ユーザーを馬鹿だと見なしている」と思う。デスクトップ環境のことを何も知らない素人のことしか考えていない。本当は、Linuxはある程度慣れた人間しか使わないはずだ。だから、一般的Linuxユーザーのことを考えていない。一般的Linuxユーザーに良いようにしたいなら、もっとUNIXとの親和性を高め、そして管理が簡単にコマンドと設定ファイルで出来るような、そういうものにしなければならないはずだ。ある意味、最近は自動設定するようになったのは良いが、もし手動設定に戻したい場合にどうすれば良いのか良く分からなかったりする。そうした、一般的なLinuxユーザー、もっと言えばパソコンオタクやIT上級者のために使いやすい機能環境を作らなければ、Linuxユーザーは減るばかりで増えることは無いだろう。
GNOMEのインターフェースは簡単にし、分かりやすくするのは良いが、本当に大切な効率性や考えなければならないこと、手間の削減のようなことを見落としている。その方が初心者向けにすることよりも優先度は高いはずだ。

新機能提案:GUIパイプ(コピー&ペーストとパイプの類似性)

僕は、X11の新しい機能の提案として、GUIパイプを提案する。
UNIXではパイプを使うことで、あるプログラムの出力を別のプログラムの入力に与えることが出来る。
僕は、GUIでテキストをコピー&ペーストしたり、いったんファイルに保存して開いたりすることが、このパイプと類似していると思う。
だから、GUIでもパイプのようにテキストとコマンドを介して、処理を自動化出来ないかと思う。
このためには、GUIのプログラムの機能をコマンドから呼び出せなければならない。
そして、実現するとこのようになる:

$ cat test.txt | msoffice.sort('A_to_Z') | msoffice.creat_toc('.table') | illustrator.make_textbox('center').set_background('black').save_png('view.png')

このようにすると、GUIのアプリケーションをコマンドで自動化し、UNIXの今までのコマンドプログラムとも連携出来る。ややオブジェクト指向のコードに似ている。
まるでGUIコマンドラインの融和を見ているようだ。

新しいデスクトップインターフェース

僕は、新しいデスクトップ環境のインターフェースを考えた。
まず、画面の一番上に、今開いているアプリケーションの一覧をアイコンで表示する。これは、Windows 7のタスクバーと同様。Dockのように動く。
そして、画面の上から二番目のバーに、アプリケーションのメニューバーを表示する。これは、Macでアプリケーションメニューを表示するのと同様。
一番上のアプリケーション一覧をタブのようにして、アプリケーションのアイコンをクリックすることでメニューバーの表示を切り替える。
その上で、その下の大きなスクリーン画面には、アプリケーションのウィンドウを表示する。
最後に、画面の一番下に、今開いているアプリケーションのウィンドウ一覧を表示する。これは、Windows XPのタスクバーと同様。
ウィンドウ一覧に表示されるのは、一番上のアプリケーションアイコン(アプリケーションタブ)で選択されたアプリケーションのみ。
そして、アプリケーションタブを画面左に表示したり(UbuntuのUnityと同様)、NeXTSTEPのようにウィンドウ一覧をDockのように表示することもできるようにする。
要するに、こんな感じ。

+-----------+----+-----------------+
| App1 App2 |App3| Computer System |
+-----------+----+-----------------+
| File Edit View Search Tools Help |
+----------------------------------+
|                                  |
|  +-------------+                 |
|  | Window2  _+x|                 |
|  +-------------+                 |
|  |             |                 |
|  |       +-------------+         |
|  |       | Window1  _+x|         |
|  |       +-------------+         |
|  +-------|             |         |
|          |             |         |
|          |             |         |
|          |             |         |
|          +-------------+         |
|                                  |
+---------+------------------------+
| Window1 | Window2 Window3        |
+---------+------------------------+

あるいは、アプリケーションアイコンからメインメニューを伸ばす感じにしてはどうだろうか。

+-----------+----+-----------------+
| App1 App2 |App3| Computer System |
+-----------+----+---+-------------+
|           | File   |             |
|           | Edit   |             |
|           | View   |             |
|  +--------| Window |             |
|  | Window2+--------+             |
|  +-------------+                 |
|  |             |                 |
|  |       +-------------+         |
|  |       | Window1  _+x|         |
|  |       +-------------+         |
|  +-------|             |         |
|          |             |         |
|          |             |         |
|          |             |         |
|          +-------------+         |
|                                  |
+---------+------------------------+
| Window1 | Window2 Window3        |
+---------+------------------------+

これは、ウィンドウ一覧もメニューにすることで、バーをひとつだけにでき、画面を巨大なバーが占領しなくても済むようにできる。

+-----------+-------+--------------+
| App1 App2 |Windows| Place System |
+-----------+-------+-+------------+
|           | Window1 |            |
|           | Window2 |            |
|           | Window3 |            |
|  +--------| Window4 |            |
|  | Window2+---------+            |
|  +-------------+                 |
|  |             |                 |
|  |       +-------------+         |
|  |       | Window1  _+x|         |
|  |       +-------------+         |
|  +-------|             |         |
|          |             |         |
|          |             |         |
|          |             |         |
|          +-------------+         |
|                                  |
|                                  |
|                                  |
+----------------------------------+

wayland

X11の代替を目指す、ディスプレイサーバ。
X11がモジュール化し、機能をクライアントとウィンドウマネージャに明け渡すことにより、X11サーバーはほとんど何もせず、データ通信をしているだけになってしまった。
そのため、X11の機能を単純化し、単純なディスプレイサーバとして、waylandと言うものが開発されている。
僕の見たところでは、今までの「のっぺり・もっさりしたGUI」が速くなるのではないか、と言う期待をしている。
Fedora 25は、GNOMEではwaylandを標準のディスプレイサーバとして採用している。

GTK/GNOME

GTK解説

コードは、「The Official GNOME 2 developer's guide」の中にあります。
以下はそのコードについての解説。
まず、gtk_init関数で初期化を行い、ウィンドウwindowをg_object_new関数で作る。
そして、g_signal_connect関数を使って、windowのdelete-eventイベントに自分で作ったdelete_event関数を、destroyイベントに自分で作ったend_program関数をコールバック関数として(関数名にG_CALLBACK()をつける)登録している。
同様に、ボタンbuttonを作った上でbuttonのclickedイベントに自分で作ったhello関数をコールバック関数として登録している。
それらが終わった後で、gtk_container_add関数を使ってコンテナとしてのwindowにウィジェットとしてのbuttonを追加し、gtk_widget_show_all関数でそれらを表示している。
最後に、gtk_main関数でアプリケーションのイベントループを開始している。

Cによるオブジェクト指向と言語バインディング

GTK/GNOMEC言語で書かれながら、GLib/GObjectという仕組みを使うことでオブジェクト指向を実現しています。
これにより、さまざまな言語のラッパーを作ることが可能です。それによって、言語バインディングが用意されています。

GTKのコードを読もう

GTKはオンラインからGitLabのリポジトリを参照することでコードを参照できる。
パソコンの初心者がパソコンを操作して、まず最初に興味を持つのはGUIツールキットではないかと思う。世間ではカーネルコンパイラばかりの内部仕様(インターナル)が解説されるが、本当は誰もが知りたいのはX11GTK/Qtのコードではないかと思う。

GNOMEのコードを読もう

Linuxの仕組みを知りたいものとして、誰もが参照したいのがGNOMEソースコード。昔はtar.gzで配布されていたものを個別に入れる必要があったが、今ではGitLabからコードをオンラインで簡単に参照でき、gitを使えばローカルにcloneするのも簡単である。
GNOMEはさまざまな技術をベースにして作られているので、全てを把握するのには時間がかかるかもしれない。だが、「Windowsに代わるOSを使いたい」のであれば、誰でも「Windowsに代わるOSを自分で開発したい」のではないだろうか。カーネルコンパイラの情報も必要だが、実際のところ自分の好きなデスクトップ環境のコードを見ることは、デスクトップ環境を「使うだけではなく開発したい」といった人に向けて開かれている、オープンな情報の在り方のひとつである。
GNOMEのコードは、以下の情報から参照できる。

Motif/CDEとGUIツールキットの歴史

旧来のUNIXでは、GUIツールキットを標準化するために、Motifというツールキットが作り出された。
これは、UNIXベンダー各社の間で共通のルック・フィールを持たせようとするものであって、Motifを拡張してHPのHP-VUEが生まれ、それを複数のベンダーが共通化してCDEが生まれた。
昔のUNIXワークステーションGUIを見ると、この伝統的で古臭いけれど味のあるCDEの画面が表示されることが多い。
MotifはOpen Motifとしてオープン化されたが、完全なフリーソフトウェアではなかった。このため、LessTifという互換フリーソフトウェアが開発された。
そして、話はLinuxになる。LinuxでもCDEのような完成されたデスクトップ環境を、特にMicrosoft Windowsに対抗して作り出そう、という動きが、KDEプロジェクトを作った。
だが、KDEはQtと呼ばれるツールキットを使っていた。優れたツールキットだったが、これはオープンソースではなかった。
フリーソフトウェアGUI環境を開発するために、GNUプロジェクトは二つの方法を同時に試した。一つは、Qtをフリーソフトウェアとして実装するHarmonyプロジェクトで、もう一つはGIMP Toolkit(GTK+)というフリーソフトウェアのツールキットを使ったデスクトップ環境を開発するGNOMEプロジェクトだ。
GNOMEは、フリーソフトウェア開発者のミゲル・デ・イカザ氏たちによって、新しい「言語非依存でWindowsのような他のOSのプログラムとも話が出来る」ものとして、CORBAと呼ばれるコンポーネント技術を採用して開発が始められた。これはWindowsのCOMと近い技術で、「UNIXをもっとマシなものにする」というミゲルの話からも分かるように、Windowsを意識したものだった。
結果的に、HarmonyではなくGNOMEが成功した。GNOMEはCで記述され、WindowsとのCORBAコンポーネントと話が出来るようなものになった。そして、GTK+PerlPythonのような他の言語からも使いやすいものになった。
現在では、Qt、Motif、CDE、どのコンポーネントオープンソースのライセンスを採用している。

GNOME 3の方向性

僕は、GNOME 3の方向性も、ある意味では間違っていないと思う。
賢くて独自性のあるシェルにして、アプリケーションの操作を単純化し、シンプルで初心者向けの簡単なものにする、と言う考え方は、パソコンの開発者なら誰でも分かる。
昔の自分も、「パソコンの分からない母親にも使えるインターフェースを作りたい」と思っていた。
だが、そのために機能性や使いやすさを犠牲にする、GNOME 3の考え方を、僕は信じない。
僕は普段、Fedora 26でMATEを使っている。MATEは動作も速いし、機能性もきちんとある。僕は、MATEでなければLinuxは使えないと思う。
たまにKDEを起動することはあっても、メインで使う環境にはならない。KDE/Qtアプリケーションの中に良いアプリケーションがない。
だから、きっとGNOME 4が出ることがあったとしても、GNOME 3をMATEと同等に維持するような、そんなプロジェクトがあっても良いのかなと思う。

GNOMEKDEの二大戦争

GNOMEKDEの二大戦争を悪いという人が居る。開発リソースの分散になって、どっちも転ぶだけだと言う。
僕は、むしろ、その通りだと思う。
GNOMEは、Mac風にメニューを二大パネルにしたぐらいから、KDEと違う独自のデスクトップ環境へのデザイン・設計の道を歩み出したと思う。
あの当時、僕は、「素晴らしいデスクトップ環境が2種類もあって、多様性がある」と思っていた。
あの当時のLinuxは、Mozilla Suite(SeaMonkey)やFirefoxなど、ブラウザにも個性があって、独自性があった。
だが、GNOME 3が出て、KDE 4が出て、一気にLinuxは悪くなった。それまでの独自なデスクトップの個性を失い、無個性なものになった。
KDE 4は、僕は最初は「本当に美しい」と思って好きになったが、Plasma 5が出て、フラットな表示になってから、「美しいようでいて、ただ無個性なだけ」だと僕は思った。
むしろ、KDE 3の方が個性があって良かったのかもしれないと今思う。
本当に、GNOMEKDEは、僕はどちらも悪いと思う。GNOMEアーキテクチャ指向で、KDEがモダンデザイン指向なのは分かるが、どちらの考え方でもない、新しいデスクトップ環境を作ってほしい。
だが、そうした「X11の多様性」を生み出したのは、他でもないKDEGNOMEの開発者だ。そこは、賞賛してしかるべきだろう。
僕は、昔からGNOMEKDEはどちらも好きだ。どちらかが良いものになって、もう一方もさらに良いものになる。それで、頑張ってほしい。
ただ、それで終わりとしたいところだが、僕は不幸にも、これ以上KDEGNOMEは良いものになりようがなく感じてしまう。
ある意味、LinuxGUIはもう、最後まで行きついてしまったところがある。これ以上、新しいものを考えることが出来ない。
ジョブズが居たら、なんて思うだろうか。むしろ、簡単に新しいものを作って「ハイ、これが次世代の革新です」と言うかもしれない。
だが、今のWindows/Linuxの開発は、もう行き着いてしまったと思う。これ以上、新しいものが出るような気がしない。家庭用ゲーム機と同じ、衰退への道を歩むのではないかと思う。
僕が思うに、アラン・ケイの発想をもう一度再考するしかないと思う。Ubuntuにそれをやってほしい。Ubuntuなら良いものが作れるかもしれない。オープンソースの良いところは、誰でも開発に参加出来るところだから、Ubuntuでなくても、他の開発者が作っても良い。だが、マイクロソフトの資金力で作れば、またありえないものが生まれる。だが、それできっと良いものは生まれないと思う。

GNOMEは賢い代わり遅い

GNOMEには、CORBA(最近ではD-Bus)によるコンポーネントの埋め込みとネットワーク通信、テーマエンジンやエクステンション、各種言語へのラッパーなど、とても賢い点が多いのだが、その分、処理速度が遅いという難点がある。
そもそも、GNOMEではintやポインタ型すら、オブジェクトの1つとして扱うためにgintやgpointerのような型を使うようになっている。そうした「オブジェクト指向の賢いデスクトップ環境」や、X Window Systemの「ネットワーク透過」まで、たくさんの賢い点があるのだが、いかんせん、GNOMEデスクトップ全体を遅くしている。
だが、最近のコンピュータリソースの処理速度の向上には目を見張るものがあり、GNOME 2のforkであるMATEを今のパソコンで使うと、とても軽く高速に動作する。
さらに問題を大きくしているのは、KDEとの連携である。KDEはさらにグラフィックスの綺麗さや豪華さに力を入れており、GNOMEより起動が遅く、メモリを食い、不安定で動かない環境もある。だが、使っていると、KDEの方が快適である。これは、GNOMEの、「機敏さはなくてもきちんと安定して動く」という「きちんと動く」特徴とは対照的である。
COMという技術のオリジナルではあるものの、GUIウィジェットツールキットとウィンドウシステムとカーネルが統合されている、「統合されたWindows」はとても使いやすい。Microsoftがいつも言っていたように、Windowsの大きな特徴は「統合」である。これは、GTK+とQtが共存して醜い不統一のツールキット環境を生み出した、今のオープンソース陣営が見習わなければならない特徴である。Windowsは醜いAPIをしているが、その分高速で機敏に動作する。昔より安定しているのは、その上で.NETというJavaと同様のVM環境にしているからである。Windowsが勝利するのは、GNOME 3を使えば良く分かる。Linuxがシェアを奪えないのは、GNOMEを知っていれば、当たり前である。
ちなみに、Javaは処理速度を優先して、値型を導入した。GNOMEは昔からWindowsで動くJavaよりも遅いが、それはgintを導入し、全面的に賢くしすぎたためではないかと僕は思う。逆に言えば、みんな、GNOMEの賢さを理解できていない。GNOMEは最高の設計をしているのに、誰にも見向きもされない。昔から、そういうものである。
GNOMEも遅すぎるという性能の遅さを昔から分かっていて、最近ではXMLベースだったGConfをバイナリブロブのdconfに変更するなど、きちんと頑張って高速化している。.NETのVMが必要だったMonoを、最近ではCにコンパイルするValaに変えている。そもそも、GNOMEはきちんと動くことなんか目指していない。ただ、賢いアーキテクチャを目指しているのは、そもそもが昔のWindowsのCOMのような言語・プラットフォーム非依存のネットワーク通信をやりたいからであり、そもそもWindowsとの連携を模索している。だから、頑張って高速化するための努力をすれば、きっと速くなるだろう。Mozilla Firefoxがやったように、機能を全て拡張機能に頼って、シンプルで軽快なデフォルトの状態を維持する、という仕組みは、GNOME 3で大々的に導入された。だが、これは不評である。それは、デフォルトの状態が「全くと言って良いほど使えない」からである。最低品質のデスクトップ環境になったとよく言われる。だが、GNOME 3は最近、「慣れると使いやすい」と言われるようになってきた。それは、拡張機能を入れればWindowsのように使えるし、入れなくてもスマホのような分かりやすいGNOME-Shellのインターフェースが、スマホ時代の今の人間たちに好評だからである。だが、僕としては、もう少しUIを整理してほしいと思う。アプリケーションによってメニューバーがあったりなかったりするのは、良いことではないと思う。GNOMEは遅いだけではなく、デザインが未熟である。昔から、「最も醜い感じを受けるデスクトップ」は、いつでもLinuxGNOMEである。
また、WindowsLinuxには、「気質の違い」というものが存在する。Windowsは、効率のために何でも統合させたがる。カーネルWindowsGUIを統合し、グラフィックス処理も統合し、IEExplorerと統合する。このため、目に見える部分では軽快で高速だが、目に見えないセキュリティホールやバグが多く、Officeのような巨大アプリケーションは良く不安定になる。GNOMEでは、そういうものを全部独立したコンポーネントにした上で、それぞれが開発するようにプロジェクトそのものを独立させ、カーネルにグラフィックス処理を統合せず、X11GTK+/GDKに分離させる。このため、目に見えて遅くなる。特に、独自のXULという技術を使っているMozillaなどは、起動に時間がかかりすぎて、反応すらしていないように思われることもある。だが、Windowsが必ずしも不安定かというと、そうでもない。Microsoftは.NETを開発し、またWindows NT時代にカーネルを書き直したこともあって、最近は安定している。Linuxが最近不安定なのは、Ubuntuなどが使い勝手を優先するコードをたくさん書いていて、自動認識を多くするようになったことで、複雑性が増えてかつ想定できない事態が発生しても簡単に直せなくなったり、あるいはオープンソースソフトウェアが増えすぎたことや巨大になったことで、Linuxの一般的な開発者の数だけでは全てを見通すことができず、Red Hatなどの会社に頼るようになって、Windowsのやり方と変わらなくなってきたからではないかと思う。そもそもGNOMEが遅いというのもあるが、LinuxカーネルGCC/Glibcなども複雑化してきており、X11も昔よりモジュラー化が進み、どんどん複雑かつ高度になったことで、昔のMulticsと全く同じ「高機能化に伴う馬鹿」が増えていることで、「全てのコンポーネントがどんどん悪くなっている」というのがあると思う。それこそ、最近はAndroidが普及したこともあって、必ずしもLinuxがウィルスやセキュリティホールとは無縁ではなくなった。逆に、昔のRed Hat Linuxなどをそのまま使っているサーバーが、アップデートを怠っていることで、Linuxセキュリティホールの拡大にとても大きく加担しているのである。Linuxはセキュアではないし、安定もしていないし、軽くもない。GNOMEは劣悪で、KDEは使っている人間が居ない。結局、そのように負け続けているのが、今のLinuxデスクトップの、誰でも分かる現状である。
ただ、言っておくと、最近はGNOME 3は本当はそんなに遅くない。本当に、Gconfをdconfにして、CORBAをD-Busに変えたせいで、速くなっている。X11はwaylandに変わって軽くなるだろう。Linuxデスクトップは、最近、Ubuntuの影響で、どんどん「初心者でも使いやすい」ものになっている。特に、日本人ユーザーが知らないこととして、海外ではLinuxはとても好意的に受け入れられている。それは、僕の英会話学校の講師が喜々としてLinuxの話題を出すようにである。そもそも、海外にはLinuxのような工業製品が多い。日本ほど、レベルの高くないものが普通なのである。日本のSONY東芝の製品が出来すぎているだけで、海外ではとても低額で使えるLinuxのような製品がたくさんあるのである。2ちゃんねるだけを見ていると、そういう発想が分からなくなる。日本人は賢いから、Linuxを使わないのである。

GNOMEはサルが好き

GNOMEプロジェクト創設者のミゲル・デ・イカザ氏が猿が好きなことから、GNOMEプロジェクトのアプリケーションには良く猿の名前がつけられている。BonoboやXamarinなどがこれに当たる。
イカザ氏はXimianというGNOMEアプリケーションの開発とサポートを行う企業を立ち上げ、.NET FrameworkUNIX環境に実装したMonoなどを開発した。その後XimianNovellやそれ以後の企業に買収され、Monoチームは存在の意義を疑われてレイオフされた。そのため、Xamarinという新しい会社を作り、.NET FrameworkiOSAndroidのアプリケーションを開発できるXamarinと呼ばれるソフトウェアを開発した。これが功を奏し、MicrosoftによってXamarinは買収された。現在はMonoチームの仲間と一緒にMicrosoftに居るはずである。彼はGNOMEの創設でCORBAを導入したほか、Midnight Commanderと呼ばれるCUIベースだがメニュー選択でファイルを操作できるファイルマネージャや、GNOMEのGnumeric表計算ソフトなどを開発し、多くのオープンソースプログラマーから「スーパーハッカー」として著名である。
後日注記:開発者のミゲルやその仲間たちがメキシコ人であることから、GNOMEは「メキシコ発のデスクトップ環境」として知られる。KDEはドイツ発祥であることから「ドイツ発のデスクトップ環境」として知られる。それぞれの個性が全く違うことからよく対比される。

Qt/KDE

デスクトップ・アプリケーション・フレームワークまで、一貫して開発する

KDEプロジェクトは、デスクトップ、アプリケーション、ライブラリまで、一貫して全てをKDEプロジェクトで開発しています。
GTK+には対応してもQtには対応しないことの多いLinuxアプリケーション界ですが、KDEでは全てをQtとKDELibで開発しています。
その目標は、「第一のLinuxデスクトップ」になることです。
GTK+/GNOMEアプリケーションが、個性的というか、独特というか、悪く言えば醜くてのっぺりしているツールキットを開発・提供しているのとは対照的に、美しく、かっこよく、センスの良いアプリケーションを作っています。
KDEアプリケーションは、見た目も多くが統一されており、高機能性が高く、とてもカッコいいのですが、いかんせん標準になれていません。いつまでも、準標準的なデスクトップです。ですが、その前に開けているビジョンと考え方は素晴らしいと思います。Linuxでは標準でないこともあって、そもそも起動すらしなかったり、起動しても日本語がまともに使えなかったり、あるいはまともに使える環境でもGNOMEよりもはるかに起動が遅いなど、たくさんの課題がありますが、「Linuxの未来をなんとか良いものとして見られるようにしてくれる」という意味で、KDEコミュニティはLinuxを陰から支えてくれています。

Xfce

XfceならMX Linux

Xfceを使うなら、中量級のディストリビューションであるMX Linuxがおすすめ。
大手ディストリビューションに見放された32bit版も開発・提供しており、Windows XPマシンに導入してもよし。

ウィンドウマネージャ

twm

twmX11の標準のウィンドウマネージャ。xtermやktermを使うならこれでも案外使える。

FVWM

古いウィンドウマネージャだが、今でも使える。軽くて速い。ICCCM互換でtwmからの亜種。
.fvwmrcをカスタマイズすれば何でも設定出来て快適である。
Linuxの神髄はこのような「ありえないウィンドウマネージャをインストールすると超軽くてカスタマイズ自由自在」というところにある。GNOMEKDEは邪道である。

CTWM

FVWMと同じくtwmからの亜種。

JWM

Cで書かれた「羽のように軽い」と言われるXorg向けのウィンドウマネージャ。
GTK+やQtといった高度なライブラリを使用せず、Xlibのみで作成されている。
通常状態で約5MBしかメモリを使用しない。パッケージの容量は76KB。ライバルはタイル型のdwm。
カスタマイズはシンプルなXMLファイルである.jwmrcを編集する。
Puppy LinuxDamn Small Linuxといったディストリビューションのデフォルトウィンドウマネージャとしても知られる。
外観はMicrosoft Windows 95に似ており、UNIX/X11環境をWindows 95の代わりとして使用できる。

IceWM, LXDE

JWMと良く似たウィンドウマネージャにIceWMがある。また、プロジェクトの方向性として似ているものにLXDEやLXQtがある。

Blackbox, Openbox, Fluxbox

OpenboxはBlackboxから派生したスタック型ウィンドウマネージャ。ICCCMとEWMHに準拠している。
同様のものにFluxboxがある。
UIが魅力的で、操作性に優れている。スタイリッシュでかっこいい。

Window Maker

Window MakerはLinux向けに使えるウィンドウマネージャ。
NeXTSTEP/OPENSTEPのGNUによる実装であるGNUstepと一緒に使われる、Linux/UNIXX11向けのウィンドウマネージャである。
余計な機能がなくシンプルで軽量。その上で、評価の高かったNeXTSTEPの互換インターフェース(完全にそっくり!)とAPIGNUstepオブジェクト指向の開発ができる)が備わっている。
特に、macOSに持ち帰ったとされる「ドック」が個性的で面白い。昔はWindow Makerを標準にしているLinuxディストリビューションもあったくらいである。
そもそもは、AfterStepを改良し、GNUstepによるデスクトップ環境とするため、ブラジル人のアルフレッド・コジマによって開発された。

Enlightenment

Enlightenmentは、GNOMEKDEのようなごてごてしているだけの醜いデスクトップ環境ではなく、「ハッと息を飲むような美しさと多機能性」を追い求めるウィンドウマネージャ。
最近はファイルマネージャやウィジェットなども備え、そしてライブラリAPIも提供するなど、ほとんどGNOME/KDEと同様の統合デスクトップ環境である。
その美しさは半端ない、と言いたいところだが、個人的に言えば、「かっこいいのはその通りなんだけど、何かがガキっぽい」美しさとカッコよさである。だが、「Linux使ってるぜ、クールだぜ」と言いたい人にはおススメである。
Bodhiとは「菩薩」、Mokshaは「解脱」の意味。enlightenmentはbodhiの英訳であり、「悟り」という意味に近い。

Moksha & Bodhi Linux

MokshaはEnlightenmentの旧バージョンE17からフォークしたデスクトップ環境。
Bodhi Linuxで利用されている。
Bodhi Linuxでは独特の雰囲気は陰をひそめ、WindowsライクなUIに変わっている。

タイル型ウィンドウマネージャ

画面を互いにオーバーラップせず、分割して表示するウィンドウマネージャ。一部では熱狂的な愛好家が居る。

  • awesome
    • タイル型ウィンドウマネージャの1つ。Cで書かれLuaで構成・拡張可能。
  • Bluetile
  • bspwm
    • タイル型ウィンドウマネージャの1つ。
  • dwm
    • タイル型ウィンドウマネージャの1つ。
  • i3
    • タイル型ウィンドウマネージャの1つ。 wmiiから派生したウィンドウマネージャで、現在も活発に開発が行なわれている。
  • Ion
    • タイル型にタブ型インターフェースを組み合わせたもの。
  • KWin
    • KDEのKWinでは、KDE SC 4.4から初歩的なタイル型インターフェースに対応している。
  • Larswm
    • 動的タイル型の一種。
  • Matchbox
    • システムトレイと1つのウィンドウをタイル型表示する。組み込みシステムや携帯機器向け。
  • Ratpoison
    • キーボード駆動式のGNU Screenを発展させたもの。
  • Scrotwm
    • 最小限の機能をサポートしたタイル型ウィンドウマネージャ。
  • Wmii
    • タイル型ウィンドウマネージャの1つ。dwmの作者が並行して開発したもの。
  • xmonad
    • タイル型ウィンドウマネージャの1つ。Haskellで書かれており、Haskellで拡張可能。

日本語入力

kinput2

kinput2+cannaの場合、.xinitrc(コマンドラインからstartxする場合)や.xsession(GUIのディスプレイマネージャからログインする場合)などにインプットエンジンの設定を記述する。

export XMODIFIERS=@im=kinput2
kinput2 -canna &

uim/IIIMF/SCIM

昔のLinuxは、kinput2+cannaWnnを使うことが多かったが、その後、uim/IIIMF/SCIMなどの新しい次世代と呼ばれるフレームワークが生まれた。
かな漢字変換エンジンも、cannaWnnから新しいAnthyなどを採用するディストリビューションが増えた。

iBus/Fcitx

最近のインプットメソッド(多言語入力エンジン)。Fedora/UbuntuなどのGNOMEなどで日本語入力を行う時は、iBusかFcitxのどちらかと、以下のかな漢字変換エンジンのどれかを組み合わせて使うのが一般的。
現在のiBus/Fcitxの場合、パッケージマネージャからインストールすることで、簡単にインプットメソッドを導入出来る。iBusGNOME 3と統合されているため、GNOMEなら簡単にインストールと設定を行うだけで日本語を入力できる。

Wnn/FreeWnn、CannaATOK-Xなど

昔あったかな漢字変換エンジンとしては、ワークステーションでも連文節変換をということで開発されたWnnとFreeWnn(1987年)、おバカな変換をするCanna(1990年)、商用のATOK-Xなどがあった。

SKK

特殊な入力方式をするかなかな漢字変換エンジン。SKKを使っているUNIXerには通が多い。
基本的に、ひらがなはローマ字でそのまま入力し(変換作業は不要)、漢字は先頭の文字をSHIFTキーを一緒に押して、漢字が終わった段階でSPACEキーを押して変換する。送り仮名がある場合は、送り仮名の先頭の文字をSHIFTキーを一緒に押す。
慣れないと難しいが、慣れると「極めて快適かつ自然」に日本語入力を行うことができる。とにかく、漢字の最初と送り仮名の最初にSHIFTを押して、変換はSPACEだと覚えておけば何とかなる。
カタカナ語はq、前候補はx、Ctrl+Jでひらがなモード、lで半角英数モード。
形態素解析をあえて使わないことで、実際に漢字をボールペンなどで筆記するのに近い入力を行うことができ、ミスが少なくなる。

Anthy

かな漢字変換エンジン。コミュニティにより活発な開発がされていたが、現在では主要開発者による開発は終了している。
後日注記:京都発! オープンソースなかな漢字変換の変遷によれば、「機械学習による識別モデルに基づいた変換」「OSSでは統計的手法の先駆けとも言える存在」とのこと。

Mozc

かな漢字変換エンジン。グーグルによる日本語入力システム「Google 日本語入力」のオープンソース版として登場。
後日注記:Googleによる日本語エンジンだが、今では多くのディストリビューションで標準。京都発! オープンソースなかな漢字変換の変遷によれば、「形態素解析を用いたかな漢字変換」「コスト最小法を採用」とのこと。

libkkc

今どきのかな漢字変換エンジン。Fedoraで標準。京都発! オープンソースなかな漢字変換の変遷によれば、「N-gramによるかな漢字変換」「ビッグデータ(巨大コーパス)を十分に活かせる」とのこと。

端末での日本語入力

また、ターミナルで日本語入力がしたい時は、uim-anthyuim-fepなどを試しましょう。「FEP」は昔のDOS時代のコンソールでの日本語入力ソフトの略称です。
X11なら、昔ながらのkinput2-cannaの設定方法をtwmとかで学ぶ、というのもアリだと思います。

端末での日本語表示

ターミナルでの日本語表示が出来ない時は、コンソール(黒画面)ならjfbterm、X11twmのような環境ならrxvt-unicode(あるいはktermなど)、ページャならlvなどを試しましょう。
後日注記:最近のLinuxでは、jfbtermではなくjのついていないfbtermを使う。Debian 10なら、(コンソールのみのインストールでも)初期インストールで最初から入っていて、設定もされているため、以下のコマンドを実行すれば日本語の表示ができる端末が起動できる。

$ fbterm

Linuxは日本語入力に大きな課題

僕がLinuxデスクトップを使っていて思うのは、「Linuxは日本語入力に大きな課題」があるということ。
標準のGNOMEGTKアプリケーションで入力できても、Atomなどでは入力できないこともあるし、そもそもきちんと動かなかったり、画面が点滅したり、入力候補が綺麗に表示されないこともある。
「標準のgeditでは日本語が綺麗に表示されないからAtomを入れたら、そもそも日本語入力自体ができなかった」といった問題がある。
欧米のLinuxユーザーにはどうでもいいことかもしれないが、日本人ユーザーにとってはLinuxデスクトップの日本語入力問題は大きな課題である。

日本語環境

タイムゾーン

タイムゾーンの情報は、/usr/share/zoneinfo/以下にバイナリファイルがあり、ここにUTCと比べてプラスマイナス何時なのかの情報が記述されている。日本は9時間早い時刻となる。
UTCとは「Universal Time Coordinated」(協定世界時)の略。セシウム原子時計によって刻まれる時刻をベースとしている。
/usr/share/zoneinfo/ディレクトリの下にあるゾーン情報ファイルを/etc/localtimeとしてコピーすることでタイムゾーンを設定できる。コピーではなくシンボリックリンクを張っても良い。
タイムゾーンの設定:

# cp /usr/share/zoneinfo/Asia/Tokyo /etc/localetime

また、一時的に変えたい時は環境変数TZを設定しても良い。

$ export TZ="Asia/Tokyo"

dateコマンドをたたいてJSTと表示されればOK。

$ date

また、CentOS7ではtimedatectlコマンドを使う。

ロケール

ロケールを作るためには、Gentoo Linuxでは/etc/locale.genに「ja_JP.UTF-8」を追加して、locale-genを実行する。
基本的に、英語と日本語のja_JP.UTF-8ロケールは作っておこう。
ロケールの設定は、LANGやLC_*の環境変数を設定する。
基本的に、 LC_ALLを設定すると、他の全ての環境変数が上書きされるため、設定すれば日本語のUnicodeの環境になる。ただ、一般的にはLC_ALLよりもLANGを設定すべきである。Gentoo Wikiの解説でも「LC_ALLを設定するのは避けるべき」だとされている。よって、「export LANG=ja_JP.UTF8」のように.bashrcあるいは.bash_profileに書けば、それだけでロケールを設定できる。
LANG=ja_JP.UTF8 lsのように環境変数を設定した上でコマンドを実行すれば、一時的に日本語の環境にした上でコマンドを実行出来る。逆に英語にした上でLANG=C lsとすることも可能。
個別のロケールを設定したい場合は、LC_MESSAGES(プログラム内部で使用するローカライズ言語)やLC_TIME(日付と時刻の書式)、LC_COLLATE、LC_CTYPE、LC_MONETARY、LC_NUMERIC、LC_PAPERなどを設定すれば良い。
実際のシステム管理では、システム全体のロケールは英語のC(UNIXでは英語のASCIIコードを表すために単に「C」とする)にしておいて、ユーザーの環境だけ、環境変数でLANGを設定する、というやり方もある。これはサーバーなどで使うために、基本的環境をCにしたい時に有効。一般ユーザでもCで使う人も居るが、これはメッセージ(ユーザーインターフェースやコマンド出力)が英語になるほか、適切に設定しないと日本語入力もできない(たぶん何とかすればできる)、ハードコアな環境になるので注意が必要。
ローカライゼーション系の環境変数を表示するには、localeコマンドを実行する。

$ locale

設定を恒久的に残したい場合は、.bashrcや.bash_profileなどに「export LANG=ja_JP.UTF-8」と記述すること。
systemdを使うCentOS 7ではlocalectlという専用のコマンドも用意されている。

Linuxの日本語環境

Linuxの日本語環境は鬼門で、ディストリビューションごとにも違う。迷った時は英語を読むぐらいの覚悟が必要。日本語入力も昔は難しかった。最近は簡単に、GNOMEでインプットメソッドを設定するだけで出来る。設定方法以前に、そもそも対応していない場合もある(KDE3派生であるTrinityでは、最近の入力システムは動かない)。Linuxに日本語は期待しない方が良い。商用OSほどの国際化がされていると高々に謳う一方で、本当は日本語なんか誰も使っていないからだ。IRCで質問する場合でも、英語で質問して英語で返ってくる、それが普通だ。

日本語と英語のバランスをどうするか

本当は、日本語環境を使ってもそんなに悪いシステムではない。だが、ほとんどのユーザーが見て、劣悪なシステムにはなっている。時間がWindowsと一緒にならないとか、文字化けするとか、フォントの種類が少ないとか、英文と日本語文を混在させた時にレイアウトがおかしいとか、色んなおかしな点がある。翻訳もきちんとされていない個所があり、設定項目などで日本語と英語が混じることも少なくない。だから、最初から英語で使って、英語の生活に慣れるという発想もおかしくはない。不思議と、英語で使うと、最初からApacheMySQLに設定も要らないし、フォントも豊富で、LibreOfficeもきちんとプロ並みに使える、という良い環境になる。決して日本語では使うな、と言いたいわけではなく、最近はインプットメソッドの設定やツールもどんどん進歩しているし、ブラウザのフォントも以前は表示できなかったきちんと太字などが表示できるようになってきた。だが、.zipファイルの中の日本語ファイル名が文字コードで文字化けするなどの不備は今でもFedoraなどで残っている。だが、インプットメソッドのような、本当に必要なところでの日本語対応はきちんとしている。だが、Debianではuimの変換候補の表示位置がおかしいなどの問題はある。
どうすれば良いかと言うと、むしろ、英語に慣れるためだと思って英語を使う生活をし、どうしても必要なところではロケールの設定も出来る、という「両刀使い」を目指すしかない。英語漬けの勉強だと思って英語を基本的に使いながら、日本語入力や日本語文書の表示(特にブラウザなど)は日本語もマルチに使えるように設定しよう。Apacheの設定も、英語のマニュアルを見ながら、日本語のHTMLの文章もサーバできちんと表示させられるように設定できるようになろう。
英語が出来ないと、海外では教養のない人間に見える。英語ぐらい分かるようになっておこう。そのためには、辞書なんか見なくて良い。英会話教室などの教室に行って6年も会話していれば、英語のメッセージは聞き取れるようになるし、英語の日本語と全く違うおかしな話し方を「どのように話していいのか」が分かるようになる。
後日注記:とはいえ、英語でLinuxのメッセージなどを見るのはハードルが少し高い。たとえば、セグメンテーションエラーなどは、Linuxのセグメント機能を知っている上で、英語も理解できなければ理解することができない。だが、エラーメッセージなどは比較的Google検索などで調べやすいメッセージだし、多くの英語のメッセージは簡単である。ただし、システムについての警告などを英語だからといって無視してOKを押すようなことはシステム管理者としては避けるべきだし、商業サーバーなどでは、顧客のデータが日本語で(たとえばホームページのHTMLファイルなど)書かれていることは多くある。こういう時はきちんと日本語ロケールを設定しよう。

文字コード

文字コードは、システム全体の文字コード、各テキストファイルの文字コードから、PHPMySQL文字コードなどがあるし、クライアント側とサーバー側で合わせる必要もあります。
今の標準はUTF-8です。ファイルは出来るだけUTF-8で作るようにしましょう。でも、Windowsで書いた文章は、どうしてもShift-JISになってしまいますし、EUC-JPと言う昔のUNIX文字コードも混在します。
後日注記:たとえば、WindowsPerlを使った場合、UTF-8でprint文を実行すると文字化けして日本語が表示できない。perlスクリプトを必ずShift-JISで作る必要がある。だが、そういうUNIXWindowsとの違いの部分が、Linuxを使えないものにしているという側面はある。Windowsで作ったShift-JISの日本語ファイル名を含むzipの圧縮ファイルは、Linuxで解凍すると文字化けしてしまう。convmvコマンドを使うことで、こうしたファイル名が文字化けしたファイルの名前を変換できる。

iconvとnkf文字コードの変換コマンド)

文字コードの変換は、iconvやnkfといったプログラムから行える。現在はiconvが標準的だが、nkfの方が古くて昔からある。

フォント

Linuxでのフォントのインストール方法

Fontcondigの場合、/usr/share/fonts/や~/.local/share/fontsにTTFまたはOTFファイルを入れるだけ(~/.fonts/もあるが非推奨)。Fontconfigはこれらのフォルダを再帰的にスキャンする。
TrueTypeの場合は、/usr/share/fonts/truetype/[フォント名]、OpenTypeの場合は、/usr/share/fonts/opentype/[フォント名]にインストールしよう。
インストールしたら、フォントキャッシュの更新をするために、以下のコマンドを実行する。

fc-cache -f -v

最近のLinuxはFontconfigを使うが、旧来のXLFD(X Logical Font Description)を使っているアプリケーションもある。
Fontcondigとは違い、Xorgは/usr/share/fonts/ディレクトリを再帰的に調べない。パスを追加するときは、フルパスを使う:

Section "Files"
    FontPath     "/usr/share/fonts/local/"
EndSection

TrueTypeとOpenType

TrueTypeとOpenTypeは、拡大縮小しても輪郭がガタガタしないスケーラブルなフォントの規格。
TrueTypeは旧式の規格で、普及しており、多くのプラットフォームやソフトウェアで使うことができる。
OpenTypeは新しい規格で、より高機能で優れているとされている。収録文字数も多い。
フォントの拡張子.ttfや.ttcや.otfは必ずしもTrueTypeとOpenTypeには対応しておらず、TrueTypeベースのOpenTypeフォントがttfまたはttc、PostScriptベースのOpenTypeフォントがotfとなる。
また、一部の化石としてビットマップフォントと呼ばれるフォントもある。ビットマップのドットによってフォントを表現する。

日本語フォントのファイルパス

また、日本語フォントのファイルパスは/usr/share/fonts/ja/TrueType/のように日本語を表す「ja」のサブディレクトリがあることがあるため、注意が必要。
昔のXでは、/usr/X11R6/lib/X11/fonts/TrueTypeのような不思議な場所にインストールされることもあった。