[PyQt] revising Q*Style support

[Hans-Peter Jansen]

Dear Phil,

while your mindset concerning Q*Style plugins is well known, please 
allow me to present an idea on how to solve this dilemma properly.

Lets start with recapitulating the obvious:

 * sometimes one would like to subclass from the built in styles, since
   there are certain tasks, that cannot be solved with style sheets

 * subclassing Q*Styles will fail miserably, if they were built as
   plugins (during the Qt build process, where this is an option)

 * all known (sane?) Qt distributions do not touch this option, hence
   they use the default of styles being built into QtGui lib

 * styles being built in would be subclassable just fine, if wrapped
   properly

 * issue to solve: determine, which of the common styles was built as
   plugin


Proposal:

I'm willing to prepare a patch to configure.py and PyQt, that:

 * add an option to _enable_ checking for/building common Q*Style
   wrappers

 * checks, which of the available styles are built as plugins and
   generate sip -x flags accordingly

 * provides the necessary sip files

The check might look similar to (built into configure.py as usual):

#include <iostream>
#include <QtGui>

int main(int argc, char * argv[])
{
    // usage: qt_dir libext
    if (argc != 3)
        return 1;
    QApplication a(argc, argv);
    QString qtdir = QString::fromLatin1(argv[1]);
    QString libext = QString::fromLatin1(argv[2]);
    QStringList styles = QStyleFactory::keys();
    foreach(QString style, styles) {
        QString plugin = qtdir + "/plugins/styles/lib" 
                               + style.toLower() 
                               + "plugin." 
                               + libext;
        QFile file(plugin);
        if (!file.exists())
            std::cout << qPrintable(style) << std::endl;
    }
    return 0;
}

The output would better be redirected into a file for further 
processing, but I'm sure, you get the idea.

It is to be expected, that the generic QStyle interface will stay pretty 
stable over time, hence it wouldn't add much of a maintenance burden.

What do you think? Does this present a sustainable approach, that has a 
chance of being accepted from you any time? Do you foresee other 
downsides?

Thanks for your consideration,
Pete