Shouldn't query for updates on settings opening

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks Mark. I guess you mean that adding the "banner" at the top of the setting grid leads to the content to be shifted down?

The specification [1] states it should have that banner, and a number/badge on the icon (which is not implemented yet).

Getting the "update available" information takes a bit of time, since it hits a remote server, we can't rely delay the loading until we get a response ... assigning to mpt to see if he has any recommendation/design comment

[1] https://wiki.ubuntu.com/SoftwareUpdates#Phone

The move is unpredictable, and I won't be the only user who got the
wrong setting because everything moved as I was about to touch the screen :)

So please let's reconsider the spec - I appreciate the delay and the
reason for it, and I appreciate the motivation for providing a nice big
clue to the user as soon as we know there are updates, but the current
implementation is not great. The big indication should be a non-moving
change in the update icon.

Mark

Setting to High, in practice there are updates almost daily and that bug leads to layout changes and selection of wrong settings

Whenever updates are available, the System Settings icon in the Dash and Launcher should have a badge, and currently does not. I've reported that as bug 1362518.

And once you enter System Settings to find out the reason for the badge, it would indeed make sense for the "Updates" icon to have the same badge too. I've reported that as bug 1362547.

However, neither of those would solve the problem described in this bug. Because on my test handset at least, the "Updates" item -- like the other semi-bureaucratic items in the grid's bottom row -- requires scrolling to make it visible. And that would be true even if we got rid of the "Updates available" item (and even moreso once the current vertical spacing inconsistencies are corrected).

Fortunately, we don't need to get rid of the "Updates available" item to solve this problem. The problem is much simpler than that: the item is being added to the layout at the wrong time.

If the phone knows that updates are available from doing an automatic check, the item should be present immediately when you open System Settings, not a couple of seconds later. And if the phone *doesn't* know that updates are available, it shouldn't find out unless/until you actually navigate to the "Updates" section and trigger a manual check, whereupon you won't be on the main screen anyway. The current behavior seems like it is incorrectly doing a manual check for updates whenever you enter System Settings at all.

The only situation where the item should slide into view, like it's doing now, is when you happen to have the System Settings main screen open at the same moment that the phone is doing its automatic check for updates. Even if (a) the automatic check was daily, (b) you had so many apps installed that updates were available every day, and (c) you averaged two entire minutes looking at the System Settings main screen per day (obviously an overestimate), you would experience this jiggle only once every 720 days.

I've created bug 1370586 to have an API added to system-image-dbus that we can use to check for updates already locally known. We can use that to set visibility properly in the update-notification plugin constructor.

I disagree, MPT. Please drop the additional "updates available"
messaging in Settings altogether, in favour of:

 * a badge or colour change of the Updates setting item
 * possibly, rearranging to put that above-the-fold to address MPT's
issue of the Updates not being immediately visible

In addition, please DO rationalise the points at which we check for
updates, as described by MPT. I'd suggest:

 * on a scheduled basis (daily),
 * on demand (when Updates is launched)
 * after updates are installed

Thanks,
Mark

Tagging for rtm or an early ota
See also bug #1336712 on dynamic icons
Idea is to add some checking on load and connecting to signals to change the icons based on state

We have bug 1336712 for making the icons dynamic based on state, that would be needed to support this approach.

See bug 1351383 tracking state based icons

This bug was fixed in the package ubuntu-system-settings - 0.3+14.10.20141001-0ubuntu1

---------------
ubuntu-system-settings (0.3+14.10.20141001-0ubuntu1) utopic; urgency=low

  [ Ken VanDine ]
  * Fixed handling of the Downloading/Installing label based on actual
    state. . Forward updateProgress signals for system updates. Layout
    fixes (LP: #1312587)
  * Use new splash screen (LP: #1376242)
  * Improved tracking download states
  * Use new target_build_number from system-image-dbus to determine
    visibility of the update notification (LP: #1355803)

  [ CI bot ]
  * Resync trunk
 -- Ubuntu daily release <email address hidden> Wed, 01 Oct 2014 16:01:54 +0000