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?
>

Because the search bar state is dependant on the searchVisible flag and the width of the panel, search & indicatorbar, not the state of the Inidcators.
Thought it better to have the state determination in a single place than to have multiple entry points.
I could have had connections to the change of various items which determine the state of the search call into a function to re-interprets that state. But it's a bit messy.

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