touch-packages team mailing list archive

[Antti Kaijanmäki <antti.kaijanmaki@xxxxxxxxxxxxx>]

As nick stated in comment #7 we need more detailed API than the current
GAction based one. I'm thinking something along the line of having QML
API's that return a progress object when you call methods such as
"enableFlightMode". The caller would then use the object to track the
status of the operation.

Once we do have the ability to track the progress of an Operation in the
UI level we can either "disable" the switches for the duration of the
ongoing operation or animate them with a "progress spinner" or
something.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity8 in Ubuntu.
https://bugs.launchpad.net/bugs/1390136

Title:
  need a transition state for indicators reflecting laggy backends

Status in the base for Ubuntu mobile products:
  Confirmed
Status in Ubuntu UX bugs:
  Fix Committed
Status in indicator-network package in Ubuntu:
  Confirmed
Status in ubuntu-system-settings package in Ubuntu:
  Confirmed
Status in unity8 package in Ubuntu:
  Triaged
Status in indicator-network source package in Utopic:
  Confirmed
Status in ubuntu-system-settings source package in Utopic:
  Confirmed
Status in indicator-network source package in Vivid:
  Confirmed
Status in ubuntu-system-settings source package in Vivid:
  Confirmed
Status in unity8 source package in Vivid:
  Triaged
Status in indicator-network package in Ubuntu RTM:
  New
Status in ubuntu-system-settings package in Ubuntu RTM:
  New
Status in unity8 package in Ubuntu RTM:
  New

Bug description:
  spawned from efforts in bug 1336715

  because the user's input toggle for airplane mode is both a reflection
  of user intent & the state of the backend....and the backend is
  unfortunately variable & lengthy to change (anywhere from 1 to ~10+
  seconds sometimes) we need to have an intermediate/transition
  state....e.g. toggle to airplane mode on....then animate somehow that
  there's a transition happening, until it either fails/succeeds

  comment from dizzypaty

  Between the user’s action of toggling the airplane switcher on and/or
  off and the backend updating the state, the indicator icon displayed
  on the statusbar should be the following: network-idle.svg

  (https://drive.google.com/drive/#folders/0BzbnWoHmYF3aZTA4WHNPYW1jeUE/0BzbnWoHmYF3aS2pVejVicktrdm8/0BzbnWoHmYF3ablBITVByRnpzdEk).

  ----------------------------
  Desired resolution

  Summary: the interface should immediately respond to user input
  confirming the action, even if the backend takes up to 20 seconds to
  actually change state.  Having the UI and backend out of sync for up
  to 30 seconds is not a problem, as long as it always goes back into
  sync after this delay.

  1.    When the user changes the flight mode toggle switch it should
  instantly change state.

  2.    The backend should then be informed of the state change.

  3.    Up to 30 seconds later the backend completes the state change

  Note: The cellular connection indicator should always display the
  backend state, not the current flight mode toggle switch state

  
  Variation - user switches the flight mode toggle on and off rapidly.

  Once a flight mode state change request has been sent to the backend
  but before a conformation that the state change is complete is
  received, all further user interactions should be buffered on the
  client.  When the client receives conformation of the state change
  from the backend it should check to see if the state is in sync with
  its buffer.  If it is in sync nothing happens and the buffer is
  cleared.  If it is not in sync another state change signal is sent to
  the backend and the buffer is cleared.

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1390136/+subscriptions