[SOLVED] QML Beginner Questions
-
Hello! I develop a game and recently found QML very useful for logic, like QtScript is, but even further. So now I want to ask a few questions about things I couldn't find in docs, but which are important.
1 In every example I see:
@import QtQuick 2.0
Item { ...@also one can omit QtQuick usage, having own plugins, like this
@import MyPlugin 1.0
MyType { ...@I want to know if it is possible to have .qml file without imports, with contents like this
@// absolutely no imports here
Object { ...@2 What if I mess with working threads in my plugins the way I somehow MOVE my objects to another thread, for example in object constructor or something?
For some cases it looks fine, because Auto Connection should use Queued whenever caller and receiver are in different threads. But how does QML binding behave when objects are taken, and how to use Blocking Queued from JS (if possible)?3 Why could anyone need .qml like this one?
@import QtQuick 2.0
Item { ... }
Rectangle { ... }@Is it meaningless ill-syntax or it is possible to have such a code for some purpose? I could only find .qml's with one object tree per file.
4 When does object construction take place? I assumed it is: construct - set each property - signal onCompleted, want to know if I'm right.
Also is that possible to pass any arguments to a constructor? What is the default object setup, who is parent in this case:
@import QtQuick 2.0
Item { ... }@We actually spawn some QObject with some plugin, so does it have a parent? suppose it does, but who: plugin? QML engine?
Those are possibly very noob questions, but I feel like if I know the answers, I can do things :D
Thanks in advance!SOLVED:
1 One better use QtQuick, primarily because of it's Item and Component, and Timer, etc. - those are not in QML by default, but are very useful.
2 I separated my plugins to "backend" and "frontend" implementation, where frontend is a QML plugin starting a new thread and registering new objects. Backend plugin is not-QML, multiple backends can be used, it is ran in frontend's worker thread. Backend is a lower abstraction of what my QML-plugin is going to solve, when QML plugin knows nothing about how task is solved and just transfers application requests.
3 QML tree should have 1 root.
4 For most of my objects I make an "init" method, which is called automaticaly on them by QML plugin itself whenever "object is constructed and has (immediately or later) backend ready".Thanks for helps :)
-
QML is not really a programming language, it is JSON style markup. So you cannot have constructor parameters, objects are instantiated using the default constructors and properties are then assigned.
It is not possible to have multiple root elements, QML hierarchies are trees and each tree starts from a single stem.
As far as I know it is not possible to have a source without any imports. Then you have no components to work with, so what's the point?
You don't "somehow" move object thread ownership, you do it upon intent, and you do connections after ownership has been finalized.
-
Thanks for the reply!
Ok, I see, not really understanding JSON, but I viewed QML more like CSS, where you "describe" stuff. That is why I asked about multiple roots and .qml from scratch. The latter would be useful for me, because my plugins do not intend to provide game-object itself, so I wanted to make following scheme: app start - create qml engine - load main .qml file - enjoy.
Then I just need not Item{} but QObject{}, does it require QtQuick? I would then fill it with new properties, as QML allows defining properties. But is there import providing such empty QObject? I will think now what to do with it, but don't really want to write a special plugin which will allow pure-QObject tree root... I thought that got to be already provided by Qt, but only found this "Item". May be:
@qmlRegisterType<QObject>("importname", 1, 0, "Game");@Does it really not provided by default without QtQuick import? Any advices?
As for threading, by "somehow" I implicitly mean intent, the question is will I brake the system or not? The second question is how do I use BlockingQueuedConnection from JS, how do I specify it there? And what if I just call an invokable method (no connections), which slots are, from script for an object with different thread affinity?
-
Well, can't you try it out? I personally get an "unknown component" error without any imports, so no, no QtObject component either.
It doesn't seem like QML offers a choice to specify the connection type, at least I don't see it. As for connections you set explicitly from C++, I don't see a reason for them to break anything as long as YOU don't do anything "illegal".
And no, QML is actually more similar to HTML, you are under the wrong impression that QML is like CSS because of the syntax similarities. The main difference between HTML and QML is the first is XML based, which is slower, more bloated and slower to type, due to having to use closing tags as well. QML like HTML describes structure, CSS only describes properties of the structure elements but not the structure itself.
No one is forcing you to use the stock QML components, if you wan you can keep it entirely to using your own, but you still have to implement them, compile them, register them and import the resulting module.
You sound like you really need to spend some time developing with existing components before you rush into anything custom. So that is what I'd recommend, don't get ahead of yourself, develop, experiment and in time you will catch up. Those questions and their answers won't do you much good as long as you are in the dark of the QML paradigm.
-
Thanks for your advices. However, I have a project to do, the faster the better, and moreover, I have a whole bunch of plugins READY, but NOT_QML. So I have to "qmlize" them all the way to make available the objects, provided by plugins, to game designers, who will actually work in QML, to bring a game rules into action.
I do not use QtQuick because I make not-a-casual game. It is better to see I guess: "Video":http://www.youtube.com/watch?v=wySHVtY_3cw. As the game is going to be CPU intensive (later on), I need to apply threading. This is why I want each plugin to run its objects in separate thread. And I have it now, with my non-qml plugins, but those qml plugin interfaces are found to be far more attractive for game design.
I registered my QObject from App (not from plugin) and it works just fine. That will do.
For now only question #2 is yet unresolved, I am going to prepare plugin exporting and then I go directly into question2 issues for my own investigation. All in all I hope for an elegant solution and do want to discuss different approaches here.