Best structure for mixed Qml/C++ app?

patrickkidd

I have an application that I want to run on desktop and tablet/mobile (prioritizing macOS/iOS). The main view is already written in QGraphicsView and the property sheets are written as QWidgets, and it is nearing release on macOS. It appears that I at least need to re-write the property sheets in QtQuick to get hardware acceleration and better touch compatibility on mobile. There are two main views - file browser (currently QListView) with two tabs and a QGraphicsView which slides over the file browser and contains many QWidget property sheets as child widgets.

What is the best way to structure this app for Qml/iOS? Qml containing the QGraphicsView? Just re-write the property sheets in Qml and embed them in C++? What are the considerations here?

Thanks!

SGaist

Hi,

The only way I am aware of to mix QtWidgets in QtQuick is KDAB's DeclarativeWidgets project. However I don't remember whether QGraphicsView is already supported. Note that you can do it the other way around using QQuickWidget.

As for your current development, what would be good to start with is separate all the "backend" code so that you can easily change the UI on top of it.

Since you are developing both for desktop and mobile, you should take the time to analyse whether the UI you have on your desktop machine can really translate as is on your mobile device screen. You may have to adapt some things and maybe completely change others. What goes well on a 27" screen won't on a 5.8" even if they are at the same resolution.

patrickkidd

@SGaist Are you suggesting that the most typical or at least most sensical approach is to have a top-level QWidgets app and embed the QtQuick components within it, as opposed to the other way around?

SGaist

Not at all. Since you were talking about having QtWidgets inside your QtQuick GUI, I just wanted to state what was available.

As I wrote before, QtQuick was not written to embed QtWidgets, hence my suggestion of taking a look at DeclarativeWidgets.

But again, please take the time to design your application so it fits in your smaller screen.

patrickkidd

Sorry if I didn't word it properly, but I was asking 1) whether QtQuick containing QWidgets was more appropriate than QWidgets containing QtQuick, and 2) if there were any other broader considerations I would have related to mixing these two, for example loss of hardware acceleration or functionality.

It sounds like you are implying that QWidgets containing QtQuick is really the way to do this.

That said, are there any other broader considerations I would have related to mixing these two, for example loss of hardware acceleration or functionality? Any other strategies I should be aware of?

SGaist

Technically, until KDAB wrote DeclarativeWidgets, you didn't had a choice. So right now: you should test
QtQuick requires OpenGL while QtWidgets not (unless you are using QOpenGLWidget)

Again, no I'm not implying anything. I gave you the available options. My main message is: make it so that changing your UI is easy and do some design and testing because of the screen constraints.

patrickkidd

It sounds like people don’t do this very often then?

SGaist

Mixing Qt widgets and Qt quick on a mobile device ?

I don't know but I would be surprised.

patrickkidd

@SGaist on mobile and/or desktop.

You would be surprised if it was common or surprised if it was uncommon?

SGaist

I would be surprised if it was common on mobile. I can't say for desktop. It depends on what type of application you write and your target OS/Device.