ほとんどのLinuxディストリビューションがKDEを標準採用しない6つの理由

公開日：2022年12月30日

KDE Plasmaは非常に優れたデスクトップ環境ですが、ほとんどのLinuxディストリビューションはGNOMEを標準採用しています。Plasmaはディストリビューションの基盤として十分な実力を持ちながら、なぜKDEベースの選択肢は少ないのでしょうか。その理由の多くは、実は技術的な事情にあるのです。

1. KDEは巨大なコードベースを持つ

KDEは多数のパーツで構成されています。ユーザーが直接操作するPlasmaデスクトップ環境に加え、バックグラウンドで動作するさまざまなライブラリやフレームワーク、そして数百に及ぶアプリケーション群です。これだけのコードを把握し、保守とサポートを継続的に担うには、相当な負担が伴います。

さらに問題はコードの総量だけではありません。各コンポーネントは長い年月をかけて進化してきたため、全体像を把握するのが難しいほどの複雑さを蓄積しています。

GNOMEはユーザー体験がシンプルなだけでなく、ソフトウェア構成そのものもシンプルです。その分、導入もしやすくなります。実際、KDEベースのディストリビューションの多くは、既存ディストロの標準デスクトップを差し替えた「代替版」として提供されており、そこまで持っていくには想像以上の労力が必要なのです。

2. リリーススケジュールが分かれている

KDEの中核体験を支える各要素は、それぞれ異なるサイクルでリリースされます。直接触れるKDE Plasmaデスクトップ、バックグラウンドのライブラリ群からなるKDE Frameworks、そして120以上のプログラム・ライブラリ・プラグインを含むKDE Gearです。

それぞれが独自のリリーススケジュールを持つため、新しいPlasmaが、まだ正式リリースされていないバージョンのFrameworksを必要とする機能とともに登場することもあります。

この多数の可動部品の追跡は、ディストリビューションメンテナにとって大きな負担です。GNOMEベースのディストロなら、最新版GNOMEのリリースに合わせて半年ごとの新バージョン公開という明快なサイクルを組めます。一方、KDEベースの場合、リリース間隔をどう設定すればよいかは一目瞭然ではありません。

3. 無限にカスタマイズできる

KDE Plasmaデスクトップは、おそらく最も自由度の高いデスクトップインターフェースです。PCを自分好みに仕上げたい技術志向のユーザーにとっては大きな魅力です。パネルを複数置いてもゼロにしてもよく、グローバルメニューバーでもアプリごとのメニューでも、ドックでもタスクバーでも思い通りにできます。

コードを書いたり追加コンポーネントを入れたりしなくても、KDE PlasmaをWindows風にもmacOS風にもGNOME風にも見せられるのです。

しかし、これは技術に不慣れな人にとっては逆効果になりえます。メニューを素早く操作しているうちにタスクバーをうっかり削除してしまい、復元方法がまったくわからない――そんな事態も起こり得ます。サポートチームにとっても、標準レイアウトの問題だけでなく、考えられるあらゆる設定状態への対応を迫られるため頭痛の種です。

カスタマイズ性はデスクトップに限りません。多くのKDEアプリも同様に細かく調整でき、長大なメニューや豊富なオプションを備えています。アプリメニューを外したり、ツールバーのアイコンを変更したり、ウィンドウ内の表示内容を変えたりできます。トラブルが起きた際、この自由度の高さが開発者とサポート双方にとって再現を難しくするのです。

4. ソフトウェアがより複雑

KDE Plasmaの「システム設定」アプリを開いてみてください。項目は事実上無限にあり、名前が似通ったカテゴリも多く、検索バーに頼らないと目的の設定を見つけるのが困難なほどです。

この傾向はKDEソフトウェア全般に当てはまります。デスクトップ環境やファイルマネージャーからテキストエディターまで、多くのアプリが独自の長い設定リストを持っています。標準搭載のターミナルの設定にさえ、かなりの時間を費やしてしまうこともあります。

各アプリの機能が多いということは、学ぶべきコードが増え、サポートすべき複雑さも増えるということです。デスクトップの各コンポーネントを理解して出荷する作業は、そこまで多機能を目指さない他のデスクトップ環境よりも、はるかに手間がかかるのです。

5. バグが多い

この高いカスタマイズ性と複雑さの結果として、KDEはバグも多くなりがちです。デスクトップが実現しようとすることが多い分、開発者がテストすべき範囲も広がります。

画面下部のウィンドウリストが開いているウィンドウを表示できればそれで済む、という話ではありません。パネルを画面の横に移動したい場合に備え、ウィンドウリストは回転したりサイズを調整したりできなければなりません。そのために必要な追加コードは、バグが入り込む余地を増やします。

同様に、「代替テーマ使用中＋自動非表示パネル＋マルチモニター環境」でしか発生しないバグも、こうした機能がすべて初期状態で使える以上、特殊なケースとして切り捨てることはできません。

KDE開発者のネイト・グレアム（Nate Graham）氏は、ポッドキャスト「Destination Linux」第261回でこの課題の一部に触れています。たとえば、外部モニターの接続・切断のたびに、カスタマイズされたデスクトップレイアウトが崩れないことを保証する難しさなどです。マルチモニター対応は、他のデスクトップ環境の方が単純に実装しやすいのです。

6. 洗練度と一貫性で劣る

こうした事情が重なった結果、体験全体の洗練度がやや欠けたものになっています。プロフェッショナルで質の高い体験を作る部品はすべて揃っています。しかし、すべてが簡単に変更できる以上、デスクトップの隅々まで見た目を完璧に保つのは至難の業です。

しかも、どれほどカスタマイズ性が高くても、簡単には解決できない問題があります。各アプリ間には多くの不統一が存在します。メニューバーを使うアプリもあれば、ハンバーガーメニュー（三本線アイコン）を使うアプリもあり、両方を併用するものさえあります。

よく見ないと気づかない問題もあります。スクロールバーの余白の違いや、DolphinやKWriteのように枠のないウィンドウの端に青い角丸の枠線がぴったり張り付いているような部分です。こうした点を直すには、開発者になってコードを読めるようになるしかありません。

こうした問題はバグではありません。対処するには、「物事はこうあるべきだ」という一貫したビジョンと共通認識が必要です。デザイン判断をデザイナーに委ね、その提案に従う姿勢、そして変更を実装できる開発者の存在が求められます。KDEコミュニティは、この3つの課題すべてに直面しているのです。

KDEはデフォルトに向かないということか？

いいえ、そういうわけではありません。KDEの採用をより魅力的にする動きもあります。ValveのSteam Deck向けKDEベースのデスクトップは、Fedora Silverblueと同様にシステムファイルを読み取り専用にしています。これにより、最新のKDEアップデートを受け取るArchベースのシステムであっても、システムを壊すリスクから守られます。ValveがFlatpakを採用している点も、常に最新のアプリを入手できる保証になっています。

Valveだけではありません。TUXEDO Computersも自社製品にKDE Plasmaを採用しています。KDEを選ぶ企業はまだ少数派ではあるものの、KDEの未来は明るいと考える十分な根拠があるのです。

著者について

バーテル（Bertel）は、AndroidやLinuxなどをテーマに数千本の記事を執筆してきた経験を持つ、生粋のテクノロジー愛好家です。MakeUseOfに参加する前は、MakeTechEasierやAndroid Policeで執筆し、後者では3,500本以上の記事を発表しました。How-To Geekでも活動しています。読者が生活に取り入れるべきテクノロジー、そして手放してもよいテクノロジーの選択を助けることに喜びを感じています。

2012年にウィリアム＆メアリー大学で歴史学と政治学の学位を取得し、以来、Android、Linux、ウェアラブル、Webアプリなどを幅広く扱うテックジャーナリストとしてキャリアを歩んでいます。