25 年間、KDE コミュニティはQt を使用してさまざまなフリー ソフトウェア製品を開発してきました。これらには、Plasma デスクトップ環境、Krita や Kdenlive などのクリエイティブ ツール、GCompris などの教育アプリ、Kontact などのグループウェア スイート、その他無数のアプリ、ユーティリティ、ウィジェットが含まれます。
Qt は、豊富な高品質のクロスプラットフォーム API で知られています。ただし、すべてのユースケースをカバーしているわけではありません。実際、これは不可能です。そこで、ギャップを埋めるために、KDE はコードを作成し、時間の経過とともに多くの KDE プロジェクトにマージされました。これらの実証済みのソリューションを KDE プロジェクトの外で再利用しやすくするために、KDE はこのコードをモジュラー ライブラリの形式で共有します。
これらのライブラリをKDE フレームワークと呼びます。
現在、幅広い機能を提供する 83 の KDE フレームワークがあります。たとえば、KNotifications を使用すると、プラットフォーム固有のコードを記述せずに、Windows、macOS、Linux、Android 上でポップアップ通知を作成できます。他のフレームワークは、Qt プログラマが使いやすいように、特殊なライブラリやインターフェイスのラッパーを提供します。たとえば、bluez-qt フレームワークは、bluez D-Bus API への Qt スタイルのインターフェイスを提供します。一部のフレームワークは、QtWidgets の一部ではない多くの便利なウィジェットを含む KWidgetsAddons など、便利なクラスのコレクションです。
Qt 開発者は、KDE フレームワークで構築されたソフトウェアを知らずに使用したことがあるかもしれません。Kate や KDevelop などの KDE アプリケーションを強化する構文強調表示フレームワークは、Qt Creator でも使用されます。
KDE フレームワークを利用することには多くの利点があります。このシリーズでは、それらのいくつかを検討し、KDE フレームワークを独自の製品に統合する方法を学ぶのに役立つ実践的な実例を提供します。
このシリーズの最初のブログでは、KConfig について紹介したいと思います。
KConfig は、最もよく使用されるフレームワークの 1 つです。これにより、開発者はファイル システムに構成データを保存および取得できます。その基本機能は Qt 独自の QSettings に似ていますが、いくつかの追加機能を提供します。
アプリケーションで KConfig を使用する前に、KConfig をビルド システムに追加する必要があります。CMake の場合、これは次のように行われます。
アプリケーションで QMake を使用する場合、必要なのは次のことだけです。
次のコードは、KConfig の基本的な使用法を示しています。
まず、KConfig オブジェクトを作成します。デフォルトでは、構成は QStandardPaths::GenericConfigLocation で指定された名前のファイルに保存されますが、正確な場所は調整できます。
構成エントリはグループに編成されます。各 KConfig オブジェクトには複数のグループを含めることができ、各グループには構成データを含む複数のキーと値のペアが含まれます。
構成エントリーを読み取るには、まず KConfig オブジェクトから KConfigGroup を作成し、次に readEntry を使用して特定のキーを照会します。readEntry はオプションのデフォルト値を取り、そのキーにデータが保存されていない場合に使用されます。
設定を書き込むには、writeEntryを使用します。データはすぐにはディスクに書き込まれません。KConfigGroup オブジェクトが破棄されると、保留中のすべての書き込み操作が実行されます。sync() メソッドを使用して、ディスクへの書き込みを強制できます。
これまでのところ、これらはすべて QSettings を通じて可能です。では、KConfig を使用する利点は何でしょうか?
QSettings と KConfig の両方で構成のカスケードが可能です。ここで、構成値は、システム全体の構成値とユーザーごとの場所の 2 つの場所から読み取られます。これにより、システム全体のデフォルトを定義できるようになり、ユーザーがその値をオーバーライドできるようになります。ただし、企業環境では、これは望ましくない場合があります。KConfig を使用すると、システム管理者は設定を不変としてマークし、ユーザーが提供されたデフォルトを上書きできないようにすることができます。これには、アプリケーションのコードを変更する必要はありません。アプリケーションは、キーが不変としてマークされているかどうかをクエリして、関連する UI パーツを無効にすることができます。
場合によっては、2 つのプロセスが同じ構成ファイルにアクセスすることがあります。ここで、あるプロセスが構成を変更したときに、それに応じて反応できるように、あるプロセスに通知することが重要です。KConfigWatcher を使用すると、構成の変更について別のプロセスに通知できます。これは D-Bus 経由で行われます。したがって、D-Bus が利用可能なシステム (つまり、Linux) でのみ動作します。
KConfig (および QSettings) のこの単純な使用法には多くの欠点があります。ライブラリ/コンパイラには、構成データ構造に関する情報がありません。ほとんどのアクセスは文字列識別子を使用して行われます。これらは入力エラーになりやすく、コンパイラーはビルド時に検証できません。また、構成エントリのデータ型 (エントリが単一の文字列であるか、文字列のリストであるか、整数であるかなど) に関する情報もありません。もう 1 つの問題は、KConfig を QML コンテキストで直接使用できないことです。
KConfig は、これら 2 つの問題を解決する KConfigXT メカニズムを提供します。これは、構成データ構造の XML 記述に基づいています。コンパイル時に、この情報は、構成へのアクセスに使用される C++ クラスを生成するために使用されます。このクラスは、QML で直接使用できるように、エントリをプロパティとして公開することもできます。
XML 記述として表現された上記の例は次のようになります。
これは myappsettings.kcfg ファイルに保存されます。
KConfigXT の動作は、別の構成ファイル myappsettings.kcfgc によって制御されます。
上記のコード例は次のようになります。
