ホーム · 全てのクラス · メインのクラス · 注釈付き · グループ別 · 関数一覧

Qtプラグインの作り方

Qtはプラグイン作成のために2つのAPIを提供しています：

• Qt自身を拡張するための高レベルAPI：カスタムデータベースドライバー、イメージ形式、テキストコーデック、カスタムスタイルなど。
• Qtアプリケーションを拡張するための低レベルAPI。

例えば、次に、Qtアプリケーションにカスタム QStyle サブクラスを書いて、それをダイナミックにロードさせたいなら、あなたは、より高レベルなAPIを使用するでしょう。 Qt Designerを拡張したいなら、あなたは低レベルAPIを使用するでしょう。

高レベルAPIが低レベルAPIの上に、構築されているためいくつかの問題(issue)が両方に共通です。

トピック：:

• 高レベルAPI：Qt拡張機能を書く
• 低レベルAPI：Qtアプリケーションを拡張する
• Pluginsのロードと検査
• ビルドキー

高レベルAPI：Qt拡張機能を書く

Qt自身を拡張するpluginを書くのは、いくつかの関数をインプリメントしたり、マクロを追加したりして、適切なプラグインのベースクラスをサブクラス化することで実現されます。

いくつかのplugin基底クラスがあります。 派生しているpluginsはデフォルトで標準のpluginディレクトリに保存されます。

しかし、どこに、 plugins ディレクトリはあるのでしょう? アプリケーションが実行されると、Qtは最初に、pluginsbaseとしてアプリケーションの実行可能なディレクトリを扱うでしょう。 例えば、アプリケーションが、 C:\Program Files\MyApp にあって、style pluginがあると、Qtは C:\Program Files\MyApp\styles を探すでしょう。(アプリケーションがどこで実行可能であるかをどう見つけるかは、 QCoreApplication::applicationDirPathを見てください。) また、QtはQTDIR/plugins(QTDIRがQtがインストールされるディレクトリ)に通常位置しているQLibraryInfo::location(QLibraryInfo::PluginsPath)によって指定されたディレクトリの中を見るでしょう。 　 　 　 　 QCoreApplication::addLibraryPath()をcallすることであなたが必要とするpathをQtの探す追加pathをして加えることができます。そして、あなた独自のpathを設定したいときは、 QCoreApplication::setLibraryPaths()をcallすることで可能となります。

あなたが作りたい MyStyle MyStyleと呼ばれる新しいクラスをpluginとして利用可能にすると仮定してください。必要なコードは簡単です:

    class MyStylePlugin : public QStylePlugin
    {
    public:
        QStringList keys() const {
            return QStringList() << "mystyle";
        }
        QStyle *create(const QString &key) {
            if (key == "mystyle")
                return new MyStyle;
            return 0;
        }
    };
    Q_EXPORT_PLUGIN(MyStylePlugin)

(注意してください： QStylePlugin は大文字小文字を区別しません。小文字のキーが使用されます。他の殆どのプラグインでは大文字小文字が区別されます。)

データベースドライバー、イメージフォーマット、テキストコーデック、および他のほとんどのpluginタイプにおいて、どんな明白なオブジェクト作成(explicit object)も必要ではありません。 Qtは必要に応じてそれらを見つけて、作成するでしょう。 コード中で明示的にスタイルをセットするでしょうから、スタイルは例外となります。 スタイルを適用するには、次のようなコードを書きます：

    QApplication::setStyle(QStyleFactory::create("MyStyle"));

いくつかのpluginのクラスでは追加の機能をインプリメントする必要があります。 各々のタイプのpluginのために再インプリメントする必要がある仮想関数については、該当のクラスドキュメントを参照して下さい。

Qtアプリケーションはどのpluginが利用可能か自動的に判断します、なぜならpluginは標準pluginのサブディレクトリに格納されるからです。 このことにより、アプリケーションはpluginを検索したりロードしたりするのにいかなるコードも必要ありません、なぜならQtがそれらのプラグインを自動に処理するからです。

pluginのデフォルトディレクトリは QTDIR/plugins ( QTDIR はQtのインストールディレクトリ) です、そのクラスのタイプがサブディレクトリになります。たとえばスタイルサブクラスのサブディレクトリは stylesとなります。 もし、あなたがアプリーケーションでpluginを使いたくて、かつ、共有のplugin pathを利用したくないならば、インストールプロセスがpluginのためのpathとアプリケーション実行時の保存pathを QSettingsなどを使って決定してあげる必要があります。 それから、アプリケーションは指定されたpathに従い QCoreApplication::addLibraryPath() の実行でpathを追加し、とあなたのpluginが利用可能となります。注意：pathの最後の部分(例えば styles)は変更できません。

アプリケーションにpluginを含める通常の方法はアプリケーションに含めてコンパイルするか他のライブラリと同様にダイナミックなライブラリとしてコンパイルする方法です。 もしpluginをロード可能な形としたい場合のひとつのアプローチは、アプリケーションディレクトリにサブディレクトリを作成しそこからpluginをそこに配置する方法です。

低レベルAPI：Qtアプリケーションを拡張する

pluginsを通してQt自身だけではなく、Qtアプリケーションも拡張することができます。 このためアプリケーションが QPluginLoaderを使用しpluginを検出しロードする必要があります。 その意味で、pluginsは、データベースドライバー、イメージ形式、テキストコーデックなどのQtの機能を拡張するものに限らず、任意の機能を提供可能です。

次のStepに伴って生じるpluginと通じてアプリケーションを機能拡張します：

1. プラグインと対話するための１つのインタフェースセット (純粋仮想関数によるクラス) を定義します。
2. インタフェースに関するQtのメタオプジェクトシステムに通知するのに Q_DECLARE_INTERFACE() マクロを使用します。
3. アプリケーションがpluginをロードするのに QPluginLoader を使用します。
4. どのpluginがインタフェースにインプリメントされているか調べるのに、 qobject_cast() を使用します。

pluginを書くためには次のStepが必要となります：

1. プラグインのクラスを定義します。それは、 QObject とpluginが提供したいインタフェースから継承します。
2. インタフェースに関しては、Qtのメタオブジェクトシステムに通知するため、 Q_INTERFACES() マクロを使用します。 　 　
3. pluginを Q_EXPORT_PLUGIN() マクロにてエクスポートします。
4. adequate .pro ファイルを使い、pluginをBuildします。

例えば、これがインタフェースクラスの定義です：

    class FilterInterface
    {
    public:
        virtual ~FilterInterface() {}
        virtual QStringList filters() const = 0;
        virtual QImage filterImage(const QString &filter, const QImage &image,
                                   QWidget *parent) = 0;
    };
    Q_DECLARE_INTERFACE(FilterInterface,
                        "com.trolltech.PlugAndPaint.FilterInterface/1.0")

ここに、そのインタフェースを実装するpluginのクラスの定義があります：

    #include <QObject>
    #include <QStringList>
    #include <QImage>
    #include <plugandpaint/interfaces.h>
    class ExtraFiltersPlugin : public QObject, public FilterInterface
    {
        Q_OBJECT
        Q_INTERFACES(FilterInterface)
    public:
        QStringList filters() const;
        QImage filterImage(const QString &filter, const QImage &image,
                           QWidget *parent);
    };

Plug & Paint の 実例ドキュメントは このプロセスを詳細に説明しています。　Qt Designer 仕様書の刊行物についての情報は Creating Custom Widgets for Qt Designer を参照して下さい。 　.

Pluginsのロードと検査

pluginsをロードするとき、Qtライブラリはpluginがロード可能か使用可能かを判断するためにいくつかの健全性チェックを行います。　これにより複数のバージョンやコンフィグレーションを共存可能とします。

• Qt libraryにリンクされたpluginは高い番号のメジャーバージョンかつ(あるいは)、マイナーバージョンをもち、低い番号のメジャーバージョンかつ(あるいは)、マイナーバージョンのものはロードされません。

  論拠： 新しいバージョンの Qt libraryにリンクされたpluginは新しい特徴を利用しているかもしれませんが、それは古いバージョンのものでは利用可能ではありません。　Trolltechはマイナーリリースだけの間に新機能とAPIを加える方針を持っています(このテストがバグ修正バージョン番号ではなく、メジャーあるいはマイナーバージョン番号を見理由です)。

• Qtライブラリと全てのpluginは build key を使ってBuildされます。Qtライブラリのビルドキーはpluginのビルドキーに対して調べられます、そして、それが一致すれば、pluginはロードされます。　ビルドキーが不一致の場合、Qtライブラリはpluginのロードを拒否します。

  論拠： 以下のビルドキーに関して論拠を見てください。

アプリケーションを拡張するためにpluginを構築するとき、pluginがアプリケーションと同様の方法で構成されていることを確実にすることが重要です。　これはアプリケーションがリリースモードで構築された場合、pluginもまたリリースモードで構築されなければいけないということです。

もしあなたがQtをデバッグとリリースモードの両方で構築し、アプリケーションはリリースモードのみで構築した場合、あなたはpluginもリリースモードで構築していることを確実にする必要があります。デフォルトで、Qtのデバッグビルドが利用可能である場合に だけ、 pluginsはデバッグモードでの構築が可能です。強制的にpluginsをリリースモードで構築するには、以下の行をpluginのプロジェクトファイルに追加してください:

    CONFIG += release

これは、pluginがアプリケーションで使用されるライブラリのバージョンと互換性があるのを確実にするでしょう。

ビルドキー

プラグインがロードされるとき、Qtは、互換性のあるプラグインのみがロードされるのを確かにするためそれぞれの構成に対してpluginのビルドキーをチェックします。；違った構成をされたいかなるpluginもロードされません。

ビルドキーは次の情報を含みます：

• アーキテクチャ、オペレーティングシステム、およびコンパイラ。

  論拠： 同じコンパイラの違ったバージョンがバイナリ互換のコードを生成しない場合、コンパイラのバージョンもビルドキーに存在します。

• Qtライブラリの構成。構成はライブラリで利用可能なAPIに影響する欠落している特徴のリストです。

  論拠： Qtライブラリの同じバージョンの2つの異なった構成はバイナリー互換性がありません。　pluginをロードするQtライブラリは、pluginがバイナリー互換性があるかどうか決定するため、(不足する)特徴のリストを使用します。

  注意： 2つの異なる構成で利用可能な特徴を利用可能なpluginの例です。しかし、plugin開発者はpluginとQtのutility classeの両方でどんな特徴が使用されているか知っている必要があります。pluginsロード時、Qt libraryは複雑な特徴、依存問合、および検証を必要とする。開発者に不要な負担が要求されると、pluginをロードのオーバーヘッドが増加します。開発時間とapplication runtime costの両方を下げるために、ビルドキーの簡単なストリング比較は使用される。

• 状況に応じて、configure scriptのコマンドラインに特別なストリングが指定されます。

  論拠： アプリケーションと共にQtライブラリのバイナリを配布するときは、これは開発者にプラグインがリンクされたこのライブラリによってのみロードされるpluginを書く一つの方法を提供します。＊＊＊訳がかなり怪しいぞ

参照されたし： QPluginLoader と QLibrary.