The Qt Quick Designer is a tool which is integrated in the Qt Creator IDE and serves the purpose of building QML GUIs in a drag n’ drop alike environment. It is mainly meant for the development of solely the visual parts and the logic of events that are supposed to only change the visual behavior. Animations can be also built using the tool. Similar to the Qt Quick Designer there is also the Qt Designer which is meant for building QWidget based UI and it’s also integrated in Qt Creator and in addition to those two there is also the Qt Design Studio, a different application but similar to Qt Quick Designer with some more features, like for example the exportation of assets from Photoshop, Sketch and/or Figma to the Qt Design Studio which then generates a runnable QML project out of that design. It all sounds very good and convenient, but what does it really look like in practice?
We have looked in more detail into the topic from a developer’s perspective and mostly for when it comes to production development and have collected here some pros and cons as well as facts and myths.
Fact
When creating views in Qt Quick Designer, 2 files are generated each time, a MyFileNameForm.ui.qml plus a MyFileName.qml file. Now let’s have a look at what these files doing.
*Form.ui.qml files
This file contains and maintains all code that implements the visual parts of the application, like Buttons, Text, etc. The Form.ui.qml files are opened and edited in the design mode by default when double clicking on or switching to those. It is possible to edit in edit mode, however Qt Creator will always open it in QtQuickDesigner at first place.
*.qml files
All logic like signal handlers, functions etc including animations is created and stored in ordinary .qml files that have the same name as the Form.ui.qml file they correspond to. Technically speaking, this file inherits the Form.ui.qml file so that it can access its children in order to apply logic and/or animations to those.
Having that said, to get this access working, alias properties are defined in the Form.ui.qml file which are addressing to the components that need to have the respective logic applied. Taking the classic Coffee Machine Example that was built using the QtQuickDesigner, if we have a look for example at the SideBar which is the bar that the user shall choose their type of coffee, we see SideBarForm.ui.qml and SideBar.qml. In SideBarForm.ui.qml we see a collection of Buttons and other visual components and at the top all 4 coffee options defined as aliases, referring to the respective buttons. Then in SideBar.qml actions are being implemented and those are for example, that if macchiato is clicked then current milk and coffee amount are set as well as the coffee selected signal is emitted.
Fact
There is no folder structure and application architecture. If we look at the Coffee Machine example, all files are stored inside the project’s root directory, except a few ones that are in imports.
Therefore, manual work is needed to apply both structure and possibly modular architecture.
Fact
No path consistency. All icon and images paths are relative. This is not optimal, especially in big projects, as assets are often changing and updated and the folder structure and/or names can do so as well. Thus it is always recommendable to a) keep the assets organized in a single folder and b) define somewhere a global function with a parameter that will return the path to that folder plus the path specified in the parameter plus the file extension. For example:
function image(path) {
return Qt.resolvedUrl(“../assets/images/” + path + “.png”);
}
The resolvedUrl function will return the resolved related to the url path, so having the images in one single place we keep consistency of it. Other than this we avoid having ugly repetitive paths like “../../../images/myImage.png” in each file we need an image, instead we use Config.image(“myImage”), a lot nicer and clean solution.
Fact
Qt Quick Designer doesn’t know about code clean up. That said, for example, x&y are set by default when the user drags&drops new components into the scene or updated when existing ones are being dragged inside the view. That said, if the user sets anchors to that item, the x&y code lines will not be removed resulting in something like this:
x: 324
y: 650
anchors.bottomMargin: 20
anchors.horizontalCenter: parent.horizontalCenter
in this case, x&y will be ignored since horizontalCenter and bottom anchors are set, however the code should be cleaned up from somebody manually.
Fact
The Qt Quick Designer doesn’t know about responsive UI. UIs created using it heavily depend on x and y axis to position items inside the window. When assigning some magic numbers as values in x & y properties, then this will statically place the item in the defined coordinates and those will remain there no matter what, meaning in other words that if we want to use the same UI in different screen resolutions we’d have to either re-implement using the correct numbers for the new resolution and maintain as much versions as the resolutions we need to support or in case for example we’re implementing a desktop application where the user can just resize the window anytime, we’ll have to do some manual work and to replace all x&y with anchors.
Having that said, the Qt Quick Designer doesn’t know about scaling either. All dimensions set in the elements, are fixed number values that won’t react to any resizing, thus manual work is absolutely needed to add this functionality as well.
Fact
Manual work is needed in order to integrate the backend in an optimal way and as such to allow the possibility to switch backends (eg. simulation vs real backend) for production, testing and evaluation.
Myth
Creating components that can be used in different projects with QtQuickDesigner is not quite the case due to the limitations mentioned above, unless if those other projects have the same screen resolution (due to x&y and fixed width and height values) as well as they maintain images in the same path, just to name a few.
Myth
Productivity and maintainability may not be optimal especially when it comes to backend integration as views basically consist of 2 different files that have to be treated separately which might cause confusion, delays and block seamless workflow.
Myth
Big projects development might be tricky due to lot of manual work needed for project architecture, structure and scalability to allow multiple features implementation.
Considering the above facts and myths below is a list of pros and cons:
Pros
- There is a separation between the visual parts and the logic.
- For a designer such tools can be useful for having a “runnable” design, maybe even run it on the device evaluating this way the UX and all about the design without having to wait for the developers to set this up.
- For a developer could be useful in a way that they have a “runnable” design reference, mostly to see pixel values, animations, etc
- It might be that still some parts can be re-used considering that some manual work is needed, like for example to replace x&y and magic numbers with anchors and relative values.
Cons
- Two files need to be maintained from which one is to be edited in edit mode and the other one in the design mode, which makes the development less fluid as implementing the component’s actions (eg onClicked) in place is one of the reasons that make QML easy and efficient.
- The developer should always make sure that all aliases are consistent when it comes to naming, and if some are deleted for any reason, should also make sure to delete all parts that using those aliases which wouldn’t be necessary in case this basic logic was implemented and maintained inside the component itself.
- A lot of limitations when it comes to complex UIs, like an automotive UI or a medical device one, can’t be really implemented this way as integration to the backend won’t easily work
- Manual work is needed to add scaling functionality and make the UI responsive
- Manual work is needed to implement some kind of architecture in the application
- Manual work is needed to create a basic folder structure – imagine having tens of views and hundreds of QML files, the lack of both structure and architecture would end up to a big mess.
- Manual works is needed for assets handling. Similarly to the previous point, using relative paths in all parts in the UI increases the risk for breaking things if an image changes directory for example and in the same time creates dependencies and introduces limitations.
Concluding, if the goal is to create a re-usable, scalable, maintainable and responsive UI then starting from scratch with manual development is the way to go no matter whether is about a big or small project; this might however change in the future if more functionality is added in the Qt Design & Development tools. If the project is a small one, for example maybe a simple printer or a coffee machine UI that is meant to run only on this specific device and thus doesn’t need to adapt to many different screens as well as re-usability, maintainability and architecture are not an issue, then going with the Qt Quick Designer proposed flow could eventually work.