First, go here http://download.qt.io/online/qt5/ to figure out the url to the version of repositories you need. For me it's linux 64 bit, so I'd click down into that path until I got to http://download.qt.io/online/qt5/linux/x64/online_repository/.
Copy this url into memory.
Then, in the repositories tab of the Qt maintenance tool, select "user defined repositories" (see image in the previous post) then to the right of where you have just clicked, paste in the url you just copied. It's difficult to tell there's even a field there, it's almost hidden. When you hit the right spot the url will paste in and you should be good to go.

mike

@gregorburger Yes, we had such an issue last week, I hope it will work soon.

Hi,

Yes, it's still qdoc that's used, it's also been updated for the QML documentation.

@Wilk it's cool! What about JSON serialization?

I will try to use your library in my project http://forum.qt.io/topic/64999/qt-micro-rest-client-framework-beta

@Emysa341
https://techbase.kde.org/Getting_Started/Sources
Not sure KOffice is in there.

Note it seems to be renamed to
Calligra Flow
https://community.kde.org/Calligra/Building/2

Hi, welcome to devnet.

A better and more portable design would be if an engine did not run its own loop. The most popular way to do that is to provide a kind of Initialize(), Frame() and Shutdown() interface that you could call from a loop provided by whatever windowing framework (most of them usually have that). The Frame() part would measure the time elapsed from last frame and advance the states proportionally to that.
If you don't want to go that path (just make sure you really don't) you could also run the two loops in parallel, starting your engine's loop in a worker thread. This leads to some synchronization issues, but with some work could be manageable.

Again - it's better if the engine does not provide it's own OpenGL bindings but uses the ones provided by the windowing framework (e.g. QOpenGLFunctions in case of Qt). There should be no problem in using GLEW along with Qt, just make sure you do your GLEW/OpenGL calls with a current GL context provided by Qt.

QGLWidget is replaced now with a more modern QOpenGLWidget. If all you need is a window and input management (like with GLFW) then consider using QWindow with an OpenGL surface format instead. You will get better performance and drop the requirement of QtWidgets module.
As for triggering the update - there's an update() method for that. You can call it how often you need and it will schedule OpenGL painting. The usual way to tackle this is either using a timer or calling update() at the end of the painting method to schedule updates "as often as possible" i.e. as often as v-sync allows.

@HappyCoder Since style requires a Component you can encapsulate in ToolBarStyle and assign it to style. The you can add a condition for style to load Component as per platform. Eg:

style: Qt.platform.os==="android" ? androidComponent : desktopComponent Component { id: androidComponent ToolBarStyle { background: Rectangle { width: parent.width height: parent.heigt color: "#fcdb00" } } } Component { id: desktopComponent ToolBarStyle { background: Rectangle { width: parent.width height: parent.heigt color: "red" } } }