C++: Wie eine verspätete Klasse neues Licht auf ein bekanntes Entwurfsmuster wirft

In der Qt-Gemeinde existiert ein Mythos: "QProxyStyle". Auf der einen Seite stehen Entwickler wie David Faure, seines Zeichens KDE-Urgestein und geschätzter Kollege des Autors, die behaupten, ein QProxyStyle sei unmöglich. Auf der anderen Seite stehen Entwickler von Qt-Erweiterungen, die einen QProxyStyle entwickelt haben wollen. Eine Spurensuche im Märchenwald deckt interessante Komplikationen bei der Anwendung eines bekannten Entwurfmusters auf.

Der Autor erinnert sich noch lebhaft an eine Diskussion, die vor einigen Jahren auf dem "qt4-tech-preview"-E-Mail-Verteiler geführt wurde: Ein Entwickler fragte, wie er Code nach Qt 4 portieren solle, der die in Qt 3 vorhandene virtuelle Methode void QButton::drawButtonLabel( QPainter* ) überschrieb, um einen MathML-Text auf einem QPushButton anzeigen zu können (QButton war in Qt 3 die Basisklasse von QPushButton, und hatte deutlich mehr Verantwortlichkeiten als ihr Qt 4-Pendant QAbstractButton).

Diese spezielle virtuelle Funktion strichen die Trolltech-Entwickler in Qt 4, zusammen mit einer stattlichen Anzahl ähnlicher Funktionen, um die Klassen-Schnittstellen zu verschlanken. Die Reduzierung von Relokationen zur Beschleunigung des Programmstarts spielte bei der Entscheidung ebenfalls eine Rolle (vergleiche Ulrich Drepper, "How To Write Shared Libraries", PDF).

Das Kopieren und Anpassen der QPushButton::paintEvent()-Implementierung in seine abgeleitete Klasse sah der Entwickler als einzig gangbaren Weg an.

Müßig zu erwähnen, dass die Lösung alles andere als perfekt ist: Sobald QPushButton::paintEvent() sich in einer neuen Qt-Version ändert, muss der Entwickler den Code in seiner Kopie nachziehen. Schlimmer noch: Der neue Code könnte ein neues Qt voraussetzen. Selbst wenn er mit gezielten #ifdefs den alten Code für ältere Qt-Versionen lauffähig hält, hat der Entwickler immer noch das Problem, dass sein Button – gegen eine ältere Qt-Version gebaut, jedoch zur Laufzeit gegen eine neue Qt-Version gebunden – unter Umständen sichtbar von "nativen" Buttons in einer Weise abweicht, die so nicht gewollt war.

void ConcreteWidget::paintEvent() {

    QPainter p( this );

    QConcreteWidgetStyleOption opt;

    initStyleOption( &opt );

    style()->drawComplexControl( QStyle::CC_ConcreteWidget, &opt, &p );

}

Die Antwort, die er von einem "Troll" (hier: Trolltech-Mitarbeiter) erhielt, lautete in etwa so: "Benutze einen Proxy-Style".

Es klingt vielversprechend: Ein Proxy-Style, eingefügt zwischen QPainter und QPushButton, der lediglich das Malen des Button-Textes (QStyle::CE_PushButtonLabel) ändert, und alle anderen Style-Operationen an den zugrunde liegenden QStyle weiter leitet. Die Existenz eines QProxyStyle einmal angenommen, könnte die Lösung ungefähr wie folgt aussehen:

class PushButtonLabelProxyStyle : public QProxyStyle {
    QWidget * const m_widget;
    QStyle * const m_style;
public:
    // ...
    explicit PushButtonLabelProxyStyle( QWidget * w )
        : QProxyStyle(),
          m_widget( w ),
          m_style( w ? w->style() : 0 )
    {
        if ( w ) w->setStyle( this );
        setSourceStyle( m_style ); // register m_style to forward calls to
    }

    ~PushButtonLabelProxyStyle() {
        if ( m_widget ) m_widget->setStyle( m_style );
    }

    void drawControl( ControlElement ce, const QStyleOption * opt,
                  QPainter * p, const QWidget * w ) const {
        if ( ce == CE_PushButtonLabel )
            drawMyPushButtonLabel( opt, p );
        else
            QProxyStyle::drawControl( ce, opt, p, w ); 

            // forwards to source style
    }

private:
    void drawMyButtonLabel( const QStyleOption * opt, QPainter * p ) const {
      // ...
    }
};

void MyPushButton::paintEvent( QPaintEvent * e ) {
    const PushButtonLabelStyleProxy proxy( this );
    QPushButton::paintEvent( e );
}

Das sieht ordentlich aus, auch wenn im Listing etwas sorglos mit dem ursprünglichen QStyle umgegangen wird. Der Code verwendet sogar das RAII-Idiom.

Es brauchte jedoch sieben Releases der Qt 4-Serie, bis QProxyStyle in Qt verfügbar war: Erst Qt 4.6 enthält ihn letztlich. Was hat die Aufnahme einer solch nützlichen Klasse so lange hinausgezögert?

Zunächst ist anzumerken, dass nicht alles Nützliche bereits in Qt enthalten ist. Hier kommen Drittanbieter ins Spiel. KDAB bietet zum Beispiel KD Tools an. Ebenso ist Qxt zu nennen, das im Übrigen bereits einen QxtProxyStyle enthält, welcher genau die Aufgabe des QProxyStyle übernehmen soll.

Der geneigte Leser sei jedoch eingeladen, mit Qt 4.5 oder QxtProxyStyle, das oben gezeigte Codefragment zu einem tatsächlich ausführbaren Beispielprogramm auszuarbeiten. Zum Beispiel eines, das den Button-Text in einem Outline-Font zeichnet, oder etwas ähnlich offensichtlich anderes.

Ohne zu viel verraten zu wollen: Es stellt sich heraus, dass es nicht funktioniert. Der Debugger kann in der Ecke stehen bleiben; wie ein Artikel in Ausgabe 9 des Trolltech-Newsletters "Qt Quarterly" zeigt, ist das Problem seit langem bekannt. Die Analyse dieses Problems wird eine gewichtige Einschränkung eines bekannten Entwurfmusters aufzeigen.