QML Object Type name which overrides standard type



  • 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


  • Moderators

    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.



  • 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.


  • Moderators

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



  • @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



  • 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. :)



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

    Eagerly awaiting to Qt 5.8 :)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.