> 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 <jh...@gmx.com> wrote: > > Sent: Monday, August 28, 2017 at 11:38 AM > > From: "Thiago Macieira" <thiago.macie...@intel.com> > > To: development@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
