[Development] Qt and IoT infographic

Mon Aug 28 21:41:15 CEST 2017

> I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
that's just for Items? If I'm mistaken, then I am very happily mistaken!

QtQuick != QML. QML is a programming language and runtime for said
language, QtQuick is a scene graph. It's possible* to use QtQuick without
QML and QML without QtQuick.

* apparently QQuickWindow has some ties to the QML engine but in my
experience you can just create new QQuickItem from c++ and add them as
child of the rootItem and it works.

-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 9:26 PM, Jason H <jhihn at gmx.com> wrote:

> > Sent: Monday, August 28, 2017 at 11:38 AM
> > From: "Thiago Macieira" <thiago.macieira at intel.com>
> > To: development at qt-project.org
> > Subject: Re: [Development] Qt and IoT infographic
> >
> > On Monday, 28 August 2017 07:01:07 PDT Jason H wrote:
> > > Onto my criticisms of Qt wrt IoT:
> > >
> > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> >
> > Right now, in KF5 (kdnssd).
>
> And who puts/[wants to put] KDE on IoT?
>
>
> > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > support for writing a RESTful server?
> >
> > Timur began working on an simple HTTP server. This is a controversial
> > decision, since we've long said that Qt should not be the tool for
> server-side
> > programs.
>
> It shouldn't be that controversial. We're just observing MVC and pushing
> it from single-process to multi-process. We're not pushing Qt for the web
> per se, just making it an equal citizen.
>
> > But I dispute your assertion that it should be "web services". That's
> why I
> > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> but
> > not web.
>
> Yes, and paint yourself into a corner of the internet again. While CoAP
> and REST are both mentioned on the web page, but it also says: "From a
> developer point of view, CoAP feels very much like HTTP. Obtaining a value
> from a sensor is not much different from obtaining a value from a Web API."
>
> I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> might be focused on IoT, but why restrict the other users to it as well?
> Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> hurdles for those that don't need it.
>
> Over time the number of examples/demos where Qt consumes web services has
> grown dramatically, but Qt apps haven't really ever been able to provide
> the internet with services. Like it or not, the internet is a bus that
> enables modern society. And the data locked in my Qt programs can't easily
> contribute to that.
>
> > > b. Remove
> > > the GL dependency for QML, so that QML can function as a way to make a
> > > headless HTTP server that makes it trivial to map HTTP requests to
> QObjects
> > > or QML Elements**.
> >
> > QML does not have a GL dependency. Or, for that matter, a graphical one.
> >
> >  ldd $QTLIBDIR/libQt5Qml.t.so.5
> >         linux-vdso.so.1 (0x00007ffe33fcf000)
> >         libQt5Network.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> > libQt5Network.t.so.5 (0x00007fcaa427a000)
> >         libQt5Core.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> > libQt5Core.t.so.5 (0x00007fcaa3bfd000)
> >         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fcaa39df000)
> >         libdl.so.2 => /lib64/libdl.so.2 (0x00007fcaa37db000)
> >         libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fcaa3453000)
> >         libm.so.6 => /lib64/libm.so.6 (0x00007fcaa3141000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007fcaa2d9b000)
> >         libz.so.1 => /lib64/libz.so.1 (0x00007fcaa2b84000)
> >         libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0
> (0x00007fcaa2916000)
> >         libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
> > (0x00007fcaa24a9000)
> >         libsystemd.so.0 => /usr/lib64/libsystemd.so.0
> (0x00007fcaa2215000)
> >         libicui18n.so.59.1 => /usr/lib64/libicui18n.so.59.1
> > (0x00007fcaa1d88000)
> >         libicuuc.so.59.1 => /usr/lib64/libicuuc.so.59.1
> (0x00007fcaa19d0000)
> >         libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0
> (0x00007fcaa1762000)
> >         libdouble-conversion.so.1 => /usr/lib64/libdouble-
> conversion.so.1
> > (0x00007fcaa1551000)
> >         libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
> (0x00007fcaa123b000)
> >         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fcaa1024000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007fcaa4bd5000)
> >         libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fcaa0e0e000)
> >         libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fcaa0be7000)
> >         libcap.so.2 => /usr/lib64/libcap.so.2 (0x00007fcaa09e2000)
> >         librt.so.1 => /lib64/librt.so.1 (0x00007fcaa07da000)
> >         liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fcaa059f000)
> >         liblz4.so.1 => /usr/lib64/liblz4.so.1 (0x00007fcaa038b000)
> >         libgcrypt.so.20 => /usr/lib64/libgcrypt.so.20
> (0x00007fcaa007b000)
> >         libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0
> (0x00007fca9fe66000)
> >         libicudata.so.59.1 => /usr/lib64/libicudata.so.59.1
> > (0x00007fca9fc65000)
> >         libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fca9f9d8000)
> >
> > No, QtGui, no GL, no X11, nothing.
>
> I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
> that's just for Items? If I'm mistaken, then I am very happily mistaken!
> _______________________________________________
> 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/20170828/59f4cd72/attachment.html>