[Development] Review for new widget module [your advices are needed]

[iman ahmadvand]

Hi Shawn.

There are 2 things here:
1.In MaterialWidgets we're not going to have lots of animations (like the
QML)
2.As i ran many tests under a regular PC, animations were smooth enough and
frame rate was pretty good BTW easing curves are there and will help us a
lot!

And about the styles, i'm pretty sure it isn't possible with existing
widgets style ! as we should have some new widgets (e.g SnackBar)
But i will think twice for minimal API changes.

Regards.
Iman.

On Tue, Oct 17, 2017 at 3:35 PM, Shawn Rutledge <Shawn.Rutledge at qt.io>
wrote:

>
> > 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:
>
> http://doc.qt.io/qt-5/style-reference.html#sliders
>
> http://doc.qt.io/qt-5/stylesheet-reference.html
>
> http://doc.qt.io/qt-5/stylesheet-examples.html#customizing-qslider  )
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171017/c050adda/attachment.html>