[Development] Optional network capabilities in QML

[Carlos Enrique Pérez Sánchez]

>
> 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.
>
I also checked the #if QT_CONFIG(qml_network) in src/quick so I agree that
you may want to optional at some point.

Images can be loaded from network URLs, for example, and git grep reveals
> that networking is used in a couple other places too.
>
Exactly. However most usages of Image are intended to load embedded or
local resources, and since there're just a few places where networking is
actually used, I think that is a waste of resources and storage space to
force every Qt Quick app to strictly link to the heavy Qt Network module.
IMO, it would be great that the relationship between Qt Quick and Qt
Network could be like the relationship between Qt Quick and Qt Svg, for
example. If you include Qt Network (Qt += network) then you can load images
from the network, if not, a warning can be shown telling you to include the
Network module.

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.
>
I see :/

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.
>
That would be great!

El jue., 18 jun. 2020 a las 4:29, Shawn Rutledge (<shawn.rutledge at qt.io>)
escribió:

>
> 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/66cc21dc/attachment.html>