[PyQt] revising Q*Style support

[Phil Thompson]

On Tue, 30 Nov 2010 22:06:17 +0100, "Hans-Peter Jansen" <hpj at urpla.net>
wrote:
> 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

...except for Windows and Mac.

>  * 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?

That's pretty much how PyQt3 works.

There is nothing stopping you or anybody else producing a separate package
containing those classes.

Phil