[Development] HEADS UP: Changes in QStyle subclasses

[BogDan]

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-Wiig at digia.com>
> To: BogDan <bog_dan_ro at yahoo.com>
> Cc: Hartmann Thomas <Thomas.Hartmann at digia.com>; "development at qt-project.org" <development at 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.Hartmann at digia.com>
>>>  To: development at 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 at qt-project.org
>>>>  http://lists.qt-project.org/mailman/listinfo/development
>>> 
>>> 
>>> 
>>>  _______________________________________________
>>>  Development mailing list
>>>  Development at qt-project.org
>>>  http://lists.qt-project.org/mailman/listinfo/development
>>> 
>>  _______________________________________________
>>  Development mailing list
>>  Development at qt-project.org
>>  http://lists.qt-project.org/mailman/listinfo/development
>