GTK4とQt6がリリース

2020-12-25

2020年12月、兼ねてより噂には上がっていたGtk4とQt6がリリースとなった。

どちらも従来のGtk3、Qt5からの大きなコンセプト変更などはないが、時代が要求するモバイルやマルチメディアの対応、ビデオカードによる支援などを強化している形だ。

終わりのはじまり?

だが、これはUnixの世界の終わりのはじまりになる可能性がある。

Gtk+はそもそもGIMPというフォトレタッチソフトウェアによって開発されたものであり、これをGNOMEが採用し、GIMPとGNOMEが協調する形でGtk+2へと進化した。 だが、この頃にはもう、GTKはGNOMEのものになっていた。 そもそもGTKのプロジェクトはGNOME配下にあるし、GTK3(GitLabの制約の関係で、途中でGtk+3からGTK3になった)は完全に「GNOME3のためのライブラリ」である。

そして、これが使いにくいのだ。 GNOMEは完全にモバイルを向いていて、リッチなUIを提供しようとはしていない。 そのせいもあり、「必要な機能がなくなった」という面が大きいし、考え方自体が大きく変わった。 そのため、Gtk+2アプリはGTK3にするためにはほぼ全面的な書き換えを必要とし、移行が困難になったものも多い。それは、本家であるGIMPも同じで、GTK4のリリース、そして GTK2のEOLに間に合わない。

公式でGTK3/4への移行の目処が立っていないのは、例えばSylpheedやLeafpadなどがある。LXDEもそうだろう。 また、Claws Mail, Inkscape, Pidginなど、GTK3バージョンが存在するものもバグが多く、なかなかメインブランチに取り込めていない。

GTK3はGNOME的な、操作をユーザーに許さないインターフェイスを強要し、操作機能を提供する場合はしっかりとプログラミングする必要がある。 GTK3はアプリケーションライブラリというよりは、あくまでGNOMEライブラリなのだ。 それでもGNOMEなしに動かない、というようなことはないが、GNOMEの流儀に従う必要がある。

もちろん、これを受け入れざるを得ないのだが、これが嫌でQtに移るプロジェクトも多い。 そして、好む好まざるに関わらず、GTK2のEOLで全面的なコード書き換えを強いられる。

Qt6はもう少し話が異なる。

Qt5はQt4が登場したときにQt3から本当に大幅な変更を加えた。これによって根本的に非互換となり、多くのソフトウェアがEOLとなってしまったが、言い換えれば生き残ったプロジェクトはQt4に変更されていた。GTKのほうはGTK2のプロジェクトが今でもかなり残っているのとは対照的だ。

Qt4は十分な機能を提供できていなかった。 だからQt4はバージョンが進むごとに機能を増加させた。 しかしその結果、一部でちぐはぐになった仕様、複雑になった仕様、扱いにくい仕様が生まれてしまった。

Qt5はそれを整理し、すっきり使えるようにした。 Qt4はまだWindows XPの時代に立体的なUIを実現していた。Windows XPとWindows 7の違いだと考えればわかりやすいし、実際KDE4のUIはWindows 7に取り込まれた部分もある。 それはつまり、時代の随分先を行ったものだったということが言えるもので、だからこそQt4には未熟な部分があった。それが成熟したのがQt5だと見ることができる。

もうひとつ大きな点として、ウェブエンジンがある。 Qt3時代はKHTMLを使っていた。もちろん、Qt4でもKHTMLを使うことはできたが、それはKDEのコンポーネントである。 Qt4にはQtWebkitというApple Webkitを使う機能を組み込んだが、Appleが新版の提供を阻んでいる面があり、GTKは古いWebkitを使わざるをえないため、webの能力がかなり貧弱であるという弱点がある。 Qt5はQtWebkitもあるが、推奨されるのはBlinkを組み込んだQtWebEngineである。これにより、なんら見劣りしないウェブ機能が簡単に搭載できるようになったのは大きい。

Qt6はQt4からQt5と話は近い。 時代にそぐわなくなってしまったものや、良いと思ったのだけどいまいちだった部分を修正し、より良い形にするとともに、うまくいった部分をより積極的に使うように変更する。

大きい点は「QMLを使う」ということだ。 QMLは結構わかりにくいが、JSONとJavaScriptの中間のような構文を持っている。「ものすごく制約のあるJavaScript」という感覚だ。 そこで、クセを減らすとともに、強い静的型付けを導入し、JavaScriptをオプションにし、QObjectとQMLに同じ内容を書かされる問題を除去する。 モジュールバージョンの指定が不要になる(これによってバージョンに基づく処理ではなく機能に基づく処理が書ける)ことと、ネイティブコードにビルドできるようになる(従来はQMLはコンパイルされたQMLで、QMLを処理するバイナリが必要だった)という点はQtの存在価値を大きく変えるようなものだ。

Qt6はそんなにまずいことをしているわけではない。 というよりも、Qt6は「Qt5の後悔を禊ぐ」という面が大きい。「できるだけ互換性を保ちつつ、機能的代替手段を用意する、その上で現代的な機能を追加し、負担になっていたものは消し、Qt5で後悔していたことは良い形に変える」というものだ。 これは、Qt4からQt5になった理由と似ている。実際、Qt5はスムーズな移行を助けたため、Qt4にとどまっているプロジェクトは少ない。

だが、問題もある。 「ウェブ上の情報はQt5よりQt4のほうが多い」ということだ。このため、新規開発者はQt5のほうがハードルが高くなっているし、混乱の元にもなっている。 そして、「言語バインディングが結構Qt5で死んだ」というのも大きな問題だ。Rubyのruby-qtbindingsもQt5に対応せずに終わった。 ゆるやかにではあるが、Qt4からQt5でも振り落とされた者たちがいるのだ。

ということは当然ながらQt6でもまた、ゆるやかにふるい落とすことになるだろう。 そして今、全体的に見ればOSS開発者は勢いを失っている。 大きなプロジェクトに飲まれてしまって、「営利的OSS」こそあれど、ホビイスト作品的OSSは次々に死んでいっているし、RubyのGemも主要なものでも随分放置されているのが分かる。 このことから、「維持するのがせいいっぱい」というプロジェクトは死ぬしかない可能性もそれなりにある。

結果として強者だけが生き残り、OSSの世界が死滅し、Unixが滅ぶ…という可能性も、ないではないと思う。 それはすぐではなくても、そのターニングポイントになるかもしれない。

想い

GTK3やQt5が出たばかりの頃は、なかなかアプリが対応せず、「まぁ、出たばかりで新しいから、そんなすぐには」みたいな言われ方をしてきた。 しかし、年数がたち、GTK4やQt6が出ることがおかしいことではないと感じる状況であっても、依然として世界はGTK3/Qt5に追いついていないのだ。

「早すぎる」とは言わないが、GTK4やQt6の登場が世界を振り落とすことにならないか、というのは気になる。GIMPだってこれからGTK3に対応しようというのだし。

これ以上待って状況が好転するのかは分からない。新しいバージョン、使いやすいバージョンを出すほうが良いのかもしれない。 だが、これが苦しい状況であるのは、確かだと思う。