> On 5 Dec 2019, at 09:14, Uwe Rathmann <[email protected]> wrote: > > Unfortunately the session about styles at the QtCS ( > https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#Future_of_QStyle_for_widgets_and_controls > ) had been moved to a time slot where I had already left. > > One thing I had planned to mention is that I consider the whole styling > concept you have in Qt today as a thing of the past for embedded UIs. > All user interfaces I have worked on in the recent years consist to > 30-50% of custom controls - and the requirement of being able to style > them is beyond the concept of QStyle and friends. > > F.e think about QPalette - what is even used for QC2. This might have > been good enough for desktop applications and its limited set of > widgets, but not for the variety of fancy controls you find on embedded UIs. > > But the problem of how to make 3rd party controls "stylable" goes back > to the very beginning of QStyle - I never had a solution for my Qwt widgets.
FWIW I did try to make that point during the session, since you weren’t there to do it yourself, that you would like to have something like a table of QVariants instead of only colors (to include things like icons and border line widths and radii), and also that the ColorRole enum should be extensible or replaced with something that is extensible (such as a string). I was thinking it would be a good start to add a high-numeric-value QPalette::ColorRole::UserRole and then you could extend that with your own enum for use in your own widgets and styles. Just as we provide Qt::UserRole for extending Qt::ItemDataRole. But alas enums cannot be inherited, so functions like QPalette::color(QPalette::ColorGroup, QPalette::ColorRole) cannot take enums that users have provided along with their custom widgets. That’s why QAIM::data() takes an int role instead of Qt::ItemDataRole, and also why enums don’t make actually make good keys. So I’m tempted to think that we could try to extend QPalette to store other data types in addition to colors, but it doesn’t look possible to maintain existing API or implementation enough to be worthwhile; and it would tend to become too much of a “kitchen sink” to keep calling it QPalette. But what to do instead then? More work is being done already at this time to get QPalette working better in Qt Quick, but maybe we should replace it with something else entirely? _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
