Code review comment for lp:~nick-dedekind/unity/phablet-greeter-indicators

W dniu 20.05.2013 16:01, Nick Dedekind pisze:
>> 23 + // because of dynamic assignment of states, we need to assign state
>> after completion.
>> 24 + Component.onCompleted: state = "initial"
>>
>> Is this really true? Why would « state: "initial" » not work?
>>
>
> Yes, it's a bit of a quirk with QML. It seems the dynamic assignments are computed after the static ones.
>
> ie.
> states: pinnedModeStates
> is assigned after
> state: "initial"
> no matter where in the code it's placed.
>
> so, when states property is assigned after state, it clears the state "initial".

I could even imagine they're evaluated in alphabetical order ;). After
all you're not supposed to rely on that order.

>> 94 - function show() {
>> 95 - search.state = "visible"
>> 96 + function show_state() {
>> 97 + return "visible"
>> 98 }
>> 99
>> 100 - function hideUp() {
>> 101 - search.state = "hiddenUp"
>> 102 + function hideUp_state() {
>> 103 + return "hiddenUp"
>> 104 }
>>
>> 169 - searchIndicator.hideUp()
>> 170 + searchIndicator.state = searchIndicator.hideUp_state()
>>
>> 177 - searchIndicator.show()
>> 178 + searchIndicator.state = searchIndicator.show_state()
>>
>> This is weird, why the _state() methods at all? Either direct names or
>> readonly props would suffice, no?
>>
>
> Done.
> Guess I'm not a fan of setting state by string from external object. :(

Well, then the previous approach (with hideUp(), show()) was one that
didn't do it, no? .state = .show_state() is IMO the same as .state =
"visible" if show_state() just returns "visible". If you want to avoid
that, a show() function that sets the state to "visible" internally was
the right way, no? Why do we need to change the hideUp() and show()
methods at all?

--
Michał Sawicz <email address hidden>
Canonical Services Ltd.