qt quick using c++ for the logic

[fearu]

Hello,

I need to create a level editor for a videogame I am making, and I thought I could do it in qml, so I can learn it and see if I like it, but I am a bit lost, because the documentation is not so clear (in my opinion) explaining the different ways/how to integrate c++ with qml. I'd appreciate if someone points me into the right direction.

I want to do an application that uses qml for the interface, but:

-Uses c++ for the logic (usually it is recommended a plugin for this I think).
-a qml element has to be loaded dynamically depending on what the c++ logic says (specifically, I load from a file the level, that is tiled, and would have to create a grid of the size that the file says). For that I found this: http://doc.qt.digia.com/qt/qdeclarat...icobjects.html and this recommends using qml bindings, what I think is a different approach than plugins, and in this case the application should be qwidget based.

What I've tried right now is just creating the hello world application from the qt creator, it uses a c++ class called qtquick2applicationviewer to load the qml, but I am not even sure if this kind of application can do what I need (specifically point 2).

[wysota]

Before you start working on this, think if QML has anything to offer for you which can't easily be done with Graphics View. If you want to load most content based on description in C++, I don't see how a declarative engine helps here.

[fearu]

Well, I'm working on my final year project, and I thought that as I am investing a lot of hours on it, I better learn something new. Also, I thought that the idea was that qml should be now the preferred way to develop qt applications, but I'm seeing that even qt desktop components are not yet included.

[wysota]

If most of functionality of your application is related to dragging static objects on some canvas, setting their properties, doing things like copy & paste, undo&redo, etc. then QtQuick doesn't have much to offer in this regard. It's about DECLARING things to happen. You can't really predeclare situations that heavily depend on the logic. I'm not saying it is not possible to do what you want with QtQuick (see the link at the end of my post), I'm just saying it will probably take you much time without any real benefits.

http://www.youtube.com/watch?v=kvWeE3kurEQ

[Talei]

To add to the complete answer done by Wysota.

Currently I'm "forced" to go with the QML because, according to the "force beyond me", this "allows" to divide logic (c++) and GUI (done without problem with Widget approach, but live it as it is...). The actual reason is that person that is not familiar with he Qt read, on digia or something, that QML is new way of designing new desktop applications (no comments here) ... so I'm stuck with designing for 2h GUI that could be done within 10 min widget way.

Depending on Your Qt knowledge level, transition is not so hard.

My thoughts about QML:
1. adds additional level of the abstraction, code more prune to the error, especially if You don't like JS/Java/JSOns style languages, QML descriptive language for the GUI. QtCreator crashed on me few times on editing QML file, and as was said here before, only primitive shapes are ready, lacking of the actual widget support atm.
2. adds additional dependences to the project. Along with the standard libraries qtcore/gui I had to ship qdeclarativeview, sql, qscripting etc. So it's something to consider, because these additional libraries are like 10+MB in size
3. communication between c++ and QML is fairly easy and is actually one of the strong points of that design, because You can actually really fast switch between GUI definitions, very handy if porting to the embedded device wit diffrent screen sizes - and to point here out, QML was designed for the embedded devices in mind

Some people say that rule is: animated GUI -> QML, statical GUI -> Widgets. I must disagree, because I did develop a game,using custom widgets, that run in FullHD at 60fps without any problem. The same goes for the custom widgets - no problem at all and they look nice (i.e. web 2.0 look like) - but that is entirely up to programmer/designer.

At the end I must say that QML, IMHO, is not something to be considered for developing widget rich applications (i.e. level editor - although, as was said by Wysota before, this can be done). If You want to design custom components for, practically every, widget then it's a good way to go.

[wysota]

Currently I'm "forced" to go with the QML because, according to the "force beyond me", this "allows" to divide logic (c++) and GUI (done without problem with Widget approach, but live it as it is...). The actual reason is that person that is not familiar with he Qt read, on digia or something, that QML is new way of designing new desktop applications (no comments here) ... so I'm stuck with designing for 2h GUI that could be done within 10 min widget way.

There is a simple way to use both QML and widgets And I'm not speaking about Qt Desktop Components. So you could "cheat" your management by going that route

[Talei]

@Wysota
Can You shed some more light on that matter .

[wysota]

@Wysota
Can You shed some more light on that matter .

You can implement a wrapper over widgets for QML so that you can use widgets in QML (as opposed to C++) without using QtQuick, e.g.:

Widget {
  HLayout {
    PushButton { 
      text: "Button 1"
      onClicked: { ... }
    }
    PushButton { }
    PushButton { }
  }
}

Widget {
  HLayout {
    PushButton { 
      text: "Button 1"
      onClicked: { ... }
    }
    PushButton { }
    PushButton { }
  }
}

To copy to clipboard, switch view to plain text mode 

etc.

[anda_skoa]

You can implement a wrapper over widgets for QML so that you can use widgets in QML (as opposed to C++) without using QtQuick, e.g.:

As demonstrated by Thomas McGuire at this year's Qt Developer Days
http://www.youtube.com/watch?v=NtXSaYpqaSQ (beginning around 16:30)

Cheers,
_

[wysota]

Yes, exactly