[Interest] QML Runtime

[Rutledge Shawn]

On 30 Jan 2013, at 1:01 PM, Bo Thorsen wrote:

> Den 30-01-2013 11:24, Rutledge Shawn skrev:
>> On 30 Jan 2013, at 10:24 AM, Mark Summerfield wrote:
>> 
>>> Hi,
>>> 
>>> I noticed that last month there was a discussion on the dev mailing list
>>> about creating a qml runtime so that people could write pure QML
>>> programs with #!/usr/bin/qml (or presumably with a file association on
>>> Windows).
>>> 
>>> I just wondered:
>>> 
>>> - Is this likely to happen?
>> The patch is here
>> 
>> https://codereview.qt-project.org/#change,43540
>> 
>> so you can test it and see whether it works well enough for you.
> 
> This seems a bit silly. I don't remember ever seeing a single file QML 
> application that wasn't totally trivial. You need more than one file.

QML could be used as a non-graphical scripting language too, FWIW.

The Component tag can be used to embed components that would otherwise be in extra QML files, but so far we don't have a way to embed images.  It would tend to be ugly.  For example Postscript is all about that, mixing vector graphics and images and scripting all in one one file, but it's usually not very readable.

> If you make this able to unpack a zip (or something else) archive in 
> memory and run the files in it, it might be useful.

On the Mac there are application packages, but then you would probably embed the "qml" tool in the package, along with all the libraries it needs.  I don't like that Apple seems to be moving away from shared frameworks, but that seems to be how it is.  Frameworks can't be distributed on the app store AFAIK.  It would be nice if a .app package could be just a collection of scripts and resources with no binary at all.

On Windows and Linux I guess you just have to make an executable and put the QML code into resources, if you want to avoid installing multiple files.  But none of these cases are pure QML.  It does have the advantage of hiding the QML, and packaging up the dependencies instead of hoping the system already has a suitable qml tool (and libraries) installed.  But it wastes bandwidth to download, disk space to store, and might result in duplicate copies in memory too, if you run multiple Qt apps with different versions of the libraries.

> Same conclusion the java people came to with the jar files.

Yep.

> Ah, of course, if the files are in a directory, then you have access to 
> other files as well.

Exactly.  There could be one qml file which is obvious at the top level, and extra stuff can easily be in subdirectories.

> Hmm, that might make sense. But if you added an 
> archive version, you have something that's deployable on many platforms 
> without platform run scripts.

So you think we need another archive format?  Or is it better to find a way to put everything into one qml file?  Or is it better to distribute separate packages for each platform?  

>>> - How would it cope with qsTr()?
>>> 
>>> - Would this mean that QML would be able to access all or most of the Qt
>>>  C++ APIs (e.g., QFile, etc.)?
>> No, adding new QtQuick APIs is still more work that needs to be done.
> 
> That's a decision I've seen debated a few times here. On one hand, QML 
> feels like a limited tool if you don't have access to the full Qt API or 
> at least a much larger subset of it. OTOH, ATM all non-trivial QML apps 
> need a C++ side anyway, so why not let people code the C++ instead of 
> trying to wrap everything.
> 
> The javascript side also has a lot of limitations. Especially because 
> there is no available framework to do real work. JS is pretty much 
> restricted to manipulate the QML objects.
> 
> As the situation is right now, I don't see the point in making it 
> possible to run a QML only app. The environment is too weak for this to 
> make sense. Sure, there are probably a few apps you can do. But the 
> overwhelming amount of QML apps will need C++ coding as well.

Yeah but it should get better over time.