QML Object Type name which overrides standard type

hugOrtega

Hello everybody,

I'm in the task of stylize standard QML controls such as Label or Button.

My first approach was to create custom Object Types in separate files (e.g. MyLabel.qml + singleton QML object) as recommended in documentation ... but then I noticed that if I create Label.qml within my resource package and redefine some properties, all Labels inside my qml files honor this properties, which is very cool.

For example, with this definition:

// Label.qml @ qrc:/my/controls
Label {
    color : "red"
}

I can use:

// main.qml
import QtQuick.Controls 2.0
import "my/controls"
ApplicationWindow {
    // ...
        Label {
            text: qsTr("Hello world")
        }
    // ...
}

Then all Labels within my application are red colored, which is exactly what I'm looking for (well, not with red color, but that's the idea). I really like this feature because I can apply styles easily and I don't have to remember non-standard names for controls (also, the code is easy to maintain)

So, my question: do you think this is a good approach, or is it more safe (for the future) to declare Object Types with custom names?

Thanks in advance,

Hugo

sierdzio

I think it might be confusing to other people editing your code - which Label is used here, stock or custom?

With custom name both the intent and use case is clear.

Still, I agree that what you propose is very convenient and useful.

jpnurmi

If you're a) implementing a complete custom style in a sense that you have .qml files in qrc:/my/controls for all controls that you use in your app, or b) if you're fine with the Default style as a fallback for the missing .qml files, then you can utilize the built-in styling system so that you don't need a custom import at all:

.pro:

QT += quickcontrols2

main.cpp:

#include <QQuickStyle>
...
// must be called _before_ loading main.qml with QQml(Application)Engine
QQuickStyle::setStyle("qrc:/my/controls");

main.qml:

import QtQuick.Controls 2.0 // uses the controls from qrc:/my/controls
// import "my/controls" <== no need

PS. In the near future, it will be also possible to specify the fallback style to one of the other built-in styles, for example Material or Universal.

sierdzio

Hah, this is solid gold! Thanks, @jpnurmi :)

hugOrtega

@sierdzio I'm fine with the semantics of default elements and the styles, I'm just looking for a mechanism for small tweaks, such as color, without have to declare a custom component only for that.

@jpnurmi that's (almost) exactly what I'm looking for, thanks. For clarification:

I implemented a small example with your recommendation and works very well. Just only a small detail: I had to use QtQuick.Templates within Label.qml of my custom styles, for example:

// Label.qml
import QtQuick.Controls 2.0
import QtQuick.Templates 2.0 as T

T.Label {
    color: "red"
}

Otherwise there is a silent error and application don't load.

It would be fantastic to have the possibility to customize Material built-in style in that way... do you have any idea how far is that future you're talking about?

Thanks a lot!

Hugo

jpnurmi

I implemented a small example with your recommendation and works very well. Just only a small detail: I had to use QtQuick.Templates within Label.qml of my custom styles, for example: ... Otherwise there is a silent error and application don't load.

The QML engine may not like if the root element matches the name of the file/component. It might be better to import into a namespace to avoid the name clash. I've seen this issue particularly in static builds. I can't test right now, but does it help if you do:

// Label.qml
import QtQuick.Controls 2.0 as C

C.Label {
    color: "red"
}

It would be fantastic to have the possibility to customize Material built-in style in that way... do you have any idea how far is that future you're talking about?

I have a patch prepared. It's not merged yet, but there might be still a chance to slip it into QQC2.1 in Qt 5.8. :)

hugOrtega

Great!... Thanks a lot for your suggestions, very very useful.

Eagerly awaiting to Qt 5.8 :)