[Interest] Role of `qmlscene` and `qml` command line tools

[Elvis Stansvik]

2016-05-06 16:27 GMT+02:00 Shawn Rutledge <Shawn.Rutledge at qt.io>:
>
>> On 06 May 2016, at 15:16, Elvis Stansvik <elvstone at gmail.com> wrote:
>>
>> Alright, I see. There's probably some JS lib out there I could use,
>> after stripping everything after Qt.application.arguments[0] up to and
>> including the '--'.
>>
>> The point about trust is valid for any application though, isn't it?
>> What's special about "here you go, run `qml main.qml`" compared to
>> "here you go, compile main.cpp and run it"? In both cases the user
>> must choose to trust the code. Or maybe I misunderstood you?
>
> Yes.  There were various Windows viruses and worms that spread around by emailing scripts (and scripts packaged into other kinds of documents), so we hope that doesn’t tend to happen with QML.  If everyone was using QML as a scripting language, it would tend to happen.  But at least you can read the QML, as opposed to QML packaged up in resources in an .exe.  But the user would have to get qml.exe somehow to run it, and trust that too.  And besides, it’s often hard to put a whole application into a single QML file (although it can be done).  And we don’t have a .qar archive format or some such, like the Java ecosystem has.  So commercial software, for convenience, can be packaged as an exe with QML resources inside, and then you have to trust the whole thing.  Maybe some users have been educated not to install exe’s from unknown sources.  Maybe a tiny percentage of them would even verify a hash provided by the author.  Whereas if you send a user a QML file in an email, they might just click on it.  (And for that matter, some will click on emailed exe’s too.)  So there has been some worry, whether we will be in danger of repeating that part of history which has already been seen with other scripting languages, if we go too far down this path.

Ah yes.

In our case we're fortunately installing the application on the target
machine ourselves before delivering it, and there won't even be an
internet connection when the machine is deployed.

>
> Whereas on Linux, if it became common practice to ship some “pure QML” apps as distro packages, at least on some distros they would be signed, and wouldn’t install if the signatures didn’t match, and the package system would make sure the application’s Qt-version requirements are satisfied.  So then you might as well not use resources, but let the package install the QML in some known location; and then it’s easier for the (super)user to make modifications if they want to, in the spirit of free software.
>
>> Another thing I realized is that my instructions to other devs for
>> working with Qt Creator becomes slightly more complicated. They'll go
>> from just
>>
>> 1. Open foo.pro in Qt Creator.
>> 2. Edit the Run Environment to set PYTHONPATH.
>> 3. Ctrl+R
>>
>> to
>>
>> 1. Open foo.pro in Qt Creator.
>> 2. Add a new Custom Executable run configuration under Projects ->
>> Run, to run `qml main.qml`.
>> 3. Edit the Run Environment to set PYTHONPATH
>> 4. Uncheck [X] Always build project before deploying it in Option ->
>> Build & Run.
>> 5. Ctrl+R
>
> You can use a .qmlproject instead of a .pro.

Aha. Thanks, didn't know about .qmlproject.

Elvis

>
>>
>> But it's not that bad.
>>
>> Anyway, thanks for the input. I also had a look at the config file
>> that `qml` uses, and it seems that what is shown in the default config
>> is pretty much all there is.
>>
>> Elvis
>