[Development] Repository request: MaterialWidgets

Mon Oct 30 14:04:25 CET 2017

Hi Oswald.

I was thinking of something like this to achieve:
QApplication::setStyle("material");

Which bring completely new styled and animated appearance That would be
nice AND Qt way though.
But we've some new widgets beside the existing widgets, for example:

Switch: https://material.io
/guidelines/components/selection-controls.html#selection-controls-switch
Discrete Slider: https://material.io
/guidelines/components/sliders.html#sliders-discrete-slider
Snack Bar: https://material.io/guidelines/components/snackbars-toasts.html#
snackbars-toasts-specs

Which requires changes in QStyle enumerators.
The two build step was a good option but what about these new widgets ?

unfortunately it seems there is no way to porting this to Qt.

On Mon, Oct 30, 2017 at 3:43 PM, Lars Knoll <lars.knoll at qt.io> wrote:

> Hi,
>
>
> > On 30 Oct 2017, at 12:56, Oswald Buddenhagen <Oswald.Buddenhagen at qt.io>
> wrote:
> >
> > On Mon, Oct 30, 2017 at 01:18:45PM +0330, iman ahmadvand wrote:
> >>   Hi Lars.
> >>   Can i now request in QTQAINFRA ?
> >>
> > no need to - it will end up on my table anyway.
> >
> > anyway, as nobody else stated it quite as clearly yet, i'll bring you
> > the bad news: Yet Another Widget Set (incl. its own API) is certainly
> > *not* what qt needs. if you are successful, you'll just fragment the qt
> > ecosystem even more, but the more likely outcome is that almost nobody
> > will care for your work.
>
> I might have misread the request, but it sounded like a new style for our
> widgets. If it is indeed a completely new API set, I agree with Ossi, that
> this will most likely not really help.
> >
> > instead, you should direct your efforts towards integrating this with
> > the existing qt widgets, as shawn suggested. not as an afterthought, but
> > as the explicit goal. that means you should work on a
> > wip/materialwidgets branch directly in qtbase. all source/binary
> > incompatible changes should be wrapped into #if
> > QT_CONFIG(new_widgets_api) (derived from a to-be-added configure
> > switch). these #if's would go away in qt6 (possibly in 2-3 years).
> >
> > of course, this approach raises the question of immediate use - nobody
> > who uses a pre-built qt would get access to the new functionality. the
> > nicest way of dealing with that i can think of is to employ the c
> > preprocessor to make it possible to build qtwidgets twice: the regular
> > build, and an optional namespaced build with the new api/abi.
>
> That could be an option. The question however is how many source/binary
> incompatible changes would be needed in the first place. There might even
> be a way around here without having to break compatibility, at least to
> most features.
>
> Cheers,
> Lars
>
> >
> >>   Best Regards.
> >>   Iman.
> >>   On Mon, Oct 30, 2017 at 11:15 AM, Lars Knoll <[1]lars.knoll at qt.io>
> wrote:
> >>
> >>     Hi,
> >>     I'be happy hosting it here.
> >>
> >>       On 30 Oct 2017, at 08:36, Jean-Michaël Celerier
> >>       <[2]jeanmichael.celerier at gmail.com> wrote:
> >>       Iman: wouldn't this be better in a separate repository ?
> >>       This way someone who wants to use it does not have to wait 6
> months
> >>       for it to be in a Qt release.
> >>
> >>     Just because some repo is hosted on qt-project, doesn't mean it has
> to
> >>     follow the Qt release cycle. The maintainer of that repo can do his
> own
> >>     releases as he sees fit.
> >>     Cheers,
> >>     Lars
> >>
> >>       You could even have it included in qpm : [3]https://www.qpm.io/
> so
> >>       that us hipsters can just do "qpm install
> com.iman.materialwidgets"
> >>       and be happy forever after.
> >>
> >>       For instance here are some already existing styles that you can
> find
> >>       on the internet for widgets:
> >>       [4]https://github.com/diversys/QtHaikuStyle
> >>       [5]https://github.com/suratovvlad/libqdark
> >>
> >>       Best,
> >>       Jean-Michaël
> >>       -------
> >>       Jean-Michaël Celerier
> >>       [6]http://www.jcelerier.name
> >>       On Mon, Oct 30, 2017 at 6:24 AM, iman ahmadvand
> >>       <[7]iman72411 at gmail.com> wrote:
> >>
> >>         Any reaction ?
> >>         _______________________________________________
> >>         Development mailing list
> >>         [8]Development at qt-project.org
> >>         [9]http://lists.qt-project.org/mailman/listinfo/development
> >>
> >>       _______________________________________________
> >>       Development mailing list
> >>       [10]Development at qt-project.org
> >>       [11]http://lists.qt-project.org/mailman/listinfo/development
> >>
> >> Links:
> >> 1. mailto:lars.knoll at qt.io/
> >> 2. mailto:jeanmichael.celerier at gmail.com/
> >> 3. https://www.qpm.io/
> >> 4. https://github.com/diversys/QtHaikuStyle
> >> 5. https://github.com/suratovvlad/libqdark
> >> 6. http://www.jcelerier.name/
> >> 7. mailto:iman72411 at gmail.com/
> >> 8. mailto:Development at qt-project.org/
> >> 9. http://lists.qt-project.org/mailman/listinfo/development
> >> 10. mailto:Development at qt-project.org/
> >> 11. 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
>
> _______________________________________________
> 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/20171030/8a4bbe8d/attachment.html>