Re: [Development] HEADS UP: Changes in QStyle subclasses
On Nov 24, 2012, at 12:09 PM, Nurmi J-P jpnu...@digia.com wrote: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Notice that QCommonStyle will stay public, providing a convenient base for full custom style implementations. We do also realize that QWindowsStyle has been a commonly used base class for custom styles. To address that, we have recently promoted some generic styling code from QWindowsStyle to QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle instead. We would like to invite anyone interested in custom styles to give it a try and let us know if any other parts should be promoted too. -- J-P Nurmi FYI, the last change of these has landed just in time for the release candidate. My apologies for causing build breaks in the rush. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Changes in QStyle subclasses
On Saturday, November 24, 2012 11:09:26 AM Nurmi J-P wrote: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Notice that QCommonStyle will stay public, providing a convenient base for full custom style implementations. We do also realize that QWindowsStyle has been a commonly used base class for custom styles. To address that, we have recently promoted some generic styling code from QWindowsStyle to QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle instead. We would like to invite anyone interested in custom styles to give it a try and let us know if any other parts should be promoted too. Sounds like a pretty sensible move. It would've been nice though to fix the existing usages (like in WebKit) before landing the change in qtbase. Now the integration of other modules as well as qt5.git is broken :( Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Changes in QStyle subclasses
Hi, we are using QWindows style as a baseline for style sheets in the Qt Quick Designer. I tried using QCommonStyle instead and it works, BUT QToolButton::arrowType does not work with QCommonStyle. It would be nice if this could be fixed, otherwise we have to subclass QCommonStyle and fix this in a custom style. Kind Regards, Thomas Hartmann Am 24/11/2012 12:09, schrieb Nurmi J-P: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Notice that QCommonStyle will stay public, providing a convenient base for full custom style implementations. We do also realize that QWindowsStyle has been a commonly used base class for custom styles. To address that, we have recently promoted some generic styling code from QWindowsStyle to QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle instead. We would like to invite anyone interested in custom styles to give it a try and let us know if any other parts should be promoted too. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Changes in QStyle subclasses
Hi again, I understand what you are trying to do. What I'm trying to say it that if you are planning to use QStyle also to draw QML Components (on all platforms) then there is no problem, otherwise if you are planning in the future (e.g. 5.1, 5.2) to deprecate QStyle and come with another solution that can be used to paint classic and qml widgets (on all platforms), then IMHO you should make QStyle* private now, before you ship 5.0, otherwise you'll *MUST* keep it for the entire Qt5 lifetime. Cheers, BogDan. - Original Message - From: Bache-Wiig Jens jens.bache-w...@digia.com To: BogDan bog_dan...@yahoo.com Cc: Hartmann Thomas thomas.hartm...@digia.com; development@qt-project.org development@qt-project.org Sent: Monday, November 26, 2012 7:47 PM Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses For the desktop components we will use QStyle by default so they look and behave as regular widgets. This means that applications with custom styles will also get QML component styling for free, avoiding the need to duplicate any styling code. I recently also made it possible to style the components using pure QML, so that a QStyle backend is not strictly required on any platform. Any new touch specific components will probably not be using QStyle though. What we are trying to do with this change is simply to remove classes like QWindowsXPStyle and QWindowsVistaStyle from polluting the public API as there is no reason applications should depend on them directly, and it makes it easier for us to adapt Qt5 to various platforms in the future without breaking binary compatibility. They are merely implementation details of their respective platform plugins. Regards, Jens Hi, Are you planning to use QStyle also to draw QML Components? Or we still need to create two separate implementations for the same platform? If we still need to create two, then IMHO you should make private everything related to QStyle. BogDan. - Original Message - From: Thomas Hartmann thomas.hartm...@digia.com To: development@qt-project.org Cc: Sent: Monday, November 26, 2012 2:55 PM Subject: Re: [Development] HEADS UP: Changes in QStyle subclasses Hi, we are using QWindows style as a baseline for style sheets in the Qt Quick Designer. I tried using QCommonStyle instead and it works, BUT QToolButton::arrowType does not work with QCommonStyle. It would be nice if this could be fixed, otherwise we have to subclass QCommonStyle and fix this in a custom style. Kind Regards, Thomas Hartmann Am 24/11/2012 12:09, schrieb Nurmi J-P: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Notice that QCommonStyle will stay public, providing a convenient base for full custom style implementations. We do also realize that QWindowsStyle has been a commonly used base class for custom styles. To address that, we have recently promoted some generic styling code from QWindowsStyle to QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle instead. We would like to invite anyone interested in custom styles to give it a try and let us know if any other parts should be promoted too. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt
Re: [Development] HEADS UP: Changes in QStyle subclasses
Op 24-11-2012 12:09, Nurmi J-P schreef: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Does this also mean that you will remove void QApplication::setStyle(QStyle* style)? This API seems useless if you can't create actual style instances any more because they are public. On the other hand, I think that that may cause issues for some applications... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
