[Development] Review for new widget module [your advices are needed]
Shawn.Rutledge at qt.io
Tue Oct 17 14:05:24 CEST 2017
> On 14 Oct 2017, at 09:33, iman ahmadvand <iman72411 at gmail.com> wrote:
> Hi everyone.
> Before I send some code base on codereview and decide whether my implementation meets the requirements, I just want to know your thoughts about design decision for the new module I’m trying to add to Qt Play ground.
> So as you probably guessed my plan is to developing a new widget module (which I’m going to name it MaterialWidgets) for Qt, a modern collection of widgets that should have the same look and feel on all platforms. All the GUI parameters and styles are taken from material style guide line(https://material.io/guidelines). You can think of MaterialWidgets as the MaterialStyle in QML design but in pure C++.
> Here is a few things to clarify:
> 1.Why someone need to use material styled widgets in Qt?
> There are a bunch of app out there that need this to be available on widgets so they can easily take the benefit of newly added widget set.
> 2.Why a new widget set? why just no to use already built-in styles?
> Material widgets are going to be a special set of controls which has animations by default,
Animations need to be done on the GPU, IMO, and the scene graph is a fine vehicle for that. If you are thinking of doing animations on the CPU with QPainter, I think that is a waste of CPU cycles, and you might have trouble making it smooth enough anyway.
And that is one reason (among others) I think it’s a good idea to stabilize the scene graph API with the goal of eventually making it public: we could try to build a widget style which uses the scene graph for rendering. (Disclaimer: I haven’t tried, and probably widgets would need a lot of re-architecting to standardize that way of styling. But wouldn’t it be nice?)
> and GUI parameters are differs from built-in QtWidgets. for an example material style has a component called ContinuousSlider which has two sub component Thumb and Track and two state On(value == 0) and Off(value != 0) and a color palette for each state, so doing this with styles can't be done unless we change the enumerators and maybe more!
Maybe it’s still worthwhile to try though, and see just how much API change is really needed.
QSS exposes the ability to style sub-components which aren’t otherwise exposed in the API, after all. (These pages explain it a bit:
More information about the Development