* I think that Universal and material styles are bundled because the user can change the current style used from the command line * For the QtNetwork stuff you need to keep in mind that a lost of stuff works with URLs. For example you can specify and "http://.." url for an Image source. If i'm not wrong this implies that QtNetwork is a strong dependency of QtQuick. * Security is a big topic, but for files you use the filesystem user/group permissions
2017-07-08 13:24 GMT+02:00 Massimo Callegari via Development < development@qt-project.org>: > Hello Qt devs, > > the Quick Controls 2 initiative is great, but I'm struggling to understand > how deployment is meant to be done. > > So for "fun" I did an experiment on Windows (but this is the same also on > other platforms): > - open Qt Creator > - create a new Quick Controls 2 default template (1 text field, 1 button, > 1 swipeview) > - select "Default" as the only style > - build and deploy with windeployqt > > For a 21Kb executable, you'll get a marvellous 61MB bundle, with a total > of 235 files in it. > > Now, I see two major issues here: > > 1) *deployqt is basically a useless tool. It doesn't consider the real > dependencies needed and copy everything every time. > In the bundle I found the network bearer plugins, when the application > clearly doesn't use any QtNetwork feature. > Same for iconengines and imageformats plugins. > In QtQuick/Controls.2 I found Material and Universal styles (106 files > total) when I clearly told Qt Creator I didn't want them. > In the same folder there are 56 files, when the app probably requires less > than 10. > > 2) Security ? There is none. > If you deploy an application using a TextField control with echoMode: > TextInput.Password, one can easily add some trivial JavaScript code to the > comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow > display/log a password. > In general, an end user can seriously mess up an application by changing a > few text files. > I'm also wondering how Linux distributions can accept this. In my KDE Neon > distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that > I can edit and compromise my system. > > Now, I'm stuck in deciding what to do with all the above. Manually > building a list of QML files needed is a nightmare. Using *deployqt and > then removing the files not needed is a nightmare as well. > > In my opinion the optimal solution would be to have an inspection tool > that identifies the exact files needed by an application that outputs a QRC > file that can be easily added to the application .pro file. A sort of > pre-building step. > No idea how this copes with the recent QML caching system and what is more > efficient between qmlc files and QRC-bundled QMLs. > > I am open to ideas and comments. Maybe I'm really missing something > obvious that I couldn't find in the online documentation. > > Cheers, > Massimo > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Filippo Cucchetto
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development