A basic Question

sierdzio

@sierdzio
oh
so only first level of scope ?

Yes, only first level, unless I am mistaken ;-) Writing from memory now. And this applies to using the component somewhere else (in a different QML file). Within single file, there are no such strict visibility restrictions.

well maybe its good IDs are not global visible or one could make some crazy spaghetti code very easy.

Yea, it can be a bit annoying in the beginning, but enforces some rather good practices in the long run.

Eeli K

@sierdzio said in A basic Question:

well maybe its good IDs are not global visible or one could make some crazy spaghetti code very easy.

Yea, it can be a bit annoying in the beginning, but enforces some rather good practices in the long run.

I agree. Otherwise there's no private/public distinction in QML (and you can bypass even this visibility restriction runtime if you really want to) but I think it's reasonable to hide those inside IDs because otherwise it would encourage messy programming style with no real components. Now we at least have a possibility to have real "implementation details", some kind of data hiding. So sometimes it feels annoying but in the long run it's better.

About the original problem, here's another possible solution. Not as nice and tidy as @sierdzio's but in some cases might it be clearer not to use nested if-elses, and if you have to change several properties based on the same conditions you would have to duplicate those conditions. Here you can just add another property to PropertyChanges.
(changed image to rect to save some work...)

import QtQuick 2.6
import QtQuick.Controls 2.2
import QtQuick.Layouts 1.1

ApplicationWindow {
    visible: true
    width: 640
    height: 480

    ColumnLayout {
        id: columnLayout
        anchors.fill: parent
        Button{onClicked: root.isConnected=!root.isConnected}
        Item {
            id: root
            property bool isConnected: false
            Layout.fillHeight: true
            Layout.fillWidth: true
            Rectangle {
                id: mainImg
                anchors.fill:parent
                
                states:[
                    State{
                        name:"conn_mouse"
                        when:root.isConnected && mouseArea.containsMouse
                        PropertyChanges {
                            target:mainImg
                            color:"red"
                        }
                    },
                    State{
                        name:"conn_no_mouse"
                        when:root.isConnected&&!mouseArea.containsMouse
                        PropertyChanges {
                            target:mainImg
                            color:"green"
                        }
                    },
                    State{
                        name:"noconn_mouse"
                        when:!root.isConnected&&mouseArea.containsMouse
                        PropertyChanges {
                            target:mainImg
                            color:"blue"
                        }
                    },
                    State{
                        name:"noconn_nomouse"
                        when:!root.isConnected&&!mouseArea.containsMouse
                        PropertyChanges {
                            target:mainImg
                            color:"yellow"
                        }
                    }
                ]
            }

            MouseArea {
                id: mouseArea
                hoverEnabled: true
                anchors.fill:parent
                onClicked: console.log("clicked")
            }
        }
    }
}

mrjj

hi
yes it might be annoying at first. Like UI of widgets being private but
save you from pain down the road.

states

Oh that is a nice class. So that would be better if m_connected state were more complex
or more than source property we wanted to changed on the clicked etc.

¨Thank you for sharing.

Eeli K

Just one stylistic note... Quick Controls 2 standard library qml code uses this extensively so it may be at least good to know even if you don't want to use it. It's alternative syntax for nested if-else. Modifying my own code, just set the rectangle color (or in sierzio's code the image source):

color: root.isConnected ? (mouseArea.containsMouse ? "red" : "green") :
       (mouseArea.containsMouse ? "blue" : "yellow")

This is from the Material style's Button.qml:

color: !control.enabled ? control.Material.hintTextColor :
            control.flat && control.highlighted ? control.Material.accentColor :
            control.highlighted ? control.Material.primaryHighlightedTextColor : control.Material.foreground

sierdzio

Heh, actually the first version of my snipped used the question mark notation, but I changed it to if-else because I thought it would be more readable.

It is definitely a good approach, and for simple cases I would recommend it - QML engine can optimize the question mark operator more heavily than if-else.

mrjj

hi
oh my gosh, is that like a c++ ternary operator that can be nested ?
But its not super readable unless really short.

GrecKo

It's the same, a c++ ternary operator can be nested.

mrjj

@GrecKo
Yep, i realized that after asking but I think i never saw one in c++
like
!m_seedsfilter ? good=true : m_seedsfilter==1 ? good=newClusters(Sp) : good=newSeed(Sp);

(ugly as hell)

GrecKo

Off-topic but it would be good = !m_seedsfilter? true : m_seedsfilter == 1 ? newClusters(Sp) : newSeed(Sp);, it's the same notation in Js and in c++

mrjj

Thanks
but was just live sample from
https://stackoverflow.com/questions/18237432/how-to-rewrite-complicated-lines-of-c-code-nested-ternary-operator/18237507
But back to topic a bit.

Do you know how much of JS that is supported in QML ?
Can i include .js stuff ?

sierdzio

@mrjj said in A basic Question:

Do you know how much of JS that is supported in QML ?
Can i include .js stuff ?

I think V4 engine implements full ECMA 5.1 specs, so you can run any JavaScript there, unless it uses newer features.

mrjj

@sierdzio said in A basic Question:

ECMA 5.1 specs

so that is pretty old ?
5.1 Edition / June 2011
https://www.ecma-international.org/ecma-262/5.1/

So most from
https://www.javascripting.com/

might not work as 6 years in Web tech is a decade ?

sierdzio

It is old, indeed. But a lot of projects like node.js, charts.js etc. seem to be working (or used to work 1-2 years back).

There is a ticket for upgrading the engine, but it lays dormant since years https://bugreports.qt.io/browse/QTBUG-47735

mrjj

@sierdzio

Ok sounds pretty good. even if older.

It is odd that its not been updated since lots of activities on QML.

Thank you for all the info :)

sierdzio

@mrjj said in A basic Question:

It is odd that its not been updated since lots of activities on QML.

There was a discussion about it on the mailing list once. If I recall it correctly, the priority for Qt devs working on QML was to keep the engine fast, and make it work 100% reliable in common QML use cases (and the most common uses are: small bindings/ assignments and short functions) - so they did not feel pressure to implement newer features.