[Development] Optional network capabilities in QML

[Shawn Rutledge]

> On 2020 Jun 17, at 10:01, Ulf Hermann <ulf.hermann at qt.io> wrote:
> 
> Hi Carlos,
> 
>> In Qt 5.15.0, I compiled QML without network support successfully, so the bug was fixed and so there's no need for the issue.
>> On the other hand, you only mention the compilation error, which is not the main topic here. So I want to ask you if I should open a bug report about making the network support in Qt Quick applications optional instead of discussing those things here with the development team.
> 
> I don't really understand this question. What exactly is the problem you are observing and what is the desired outcome? -no-feature-qml-network should have the effect of not linking QtNetwork into QtQml. QtQuick is indeed a somewhat different story. I would have to research how network support is handled there, and I'm in favor of making it optional if it is not. 

I agree, it’s supposed to be optional.  There are some #if QT_CONFIG(qml_network) in src/quick, but it’s possible that we could be missing some. 

But I just did a build like that on Linux, which completed successfully:

../qt5/configure -prefix /home/rutledge/dev/qt5-no-net/qtbase -release -confirm-license -opensource -nomake examples -nomake tests -no-pch -qt-libmd4c -no-qml-network

(Some of those flags are unrelated of course.). But I suppose you could make the size smaller by leaving out networking features throughout Qt.

We have a lot of feature flags, so many useful combinations of them are not tested often enough in practice.  For example, we cannot afford to test combinations of them in CI with every patch being integrated.  One machine in the office is periodically testing disabling individual features though… in the qtbase repo.  It needs to test the rest of the essentials eventually.  And dealing with the results of that should probably be organized a bit better.  If the build breaks with some feature disabled, and bisect could be automated, maybe the hypothetical bot could comment on the patch that broke it, ideally.

> Maybe you're confused about the difference between QtQml and QtQuick. QtQml is about QML, the language. You can write all kinds of applications in QML, not necessarily graphical ones. QtQuick is graphical toolkit, providing Item, Rectangle, Image etc, for QML. It's a separate library with separate dependencies.

Images can be loaded from network URLs, for example, and git grep reveals that networking is used in a couple other places too.

IMO we could in the long term try to add a feature like KIO (but better architected) into qtcore: an abstraction over file I/O (or at some other level) that can use plugins to load files from other sources, such as web servers, ssh, adb, IPFS, etc.  Then we wouldn’t need such ad-hoc code in Qt Quick to load images via HTTP, for example.  But that’s another topic.  I was thinking of bringing it up at some point, but it’s just a fuzzy idea in my head, since I haven’t been using the existing solutions enough to have great ideas about what it ought to look like.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200618/928ca857/attachment.html>