The u/i cannot handle the array-of-dictionaries update descriptions

This bug was fixed in the package ubuntu-system-settings - 0.1+13.10.20130930-0ubuntu1

---------------
ubuntu-system-settings (0.1+13.10.20130930-0ubuntu1) saucy; urgency=low

  [ Sebastien Bacher ]
  * update: hide the description of the updates from the panel, since
    the current version of the server doesn't provide those information.
    (see bug #1215586 for details). (LP: #1215586)
  * cellular: - use the new itemselector widget rather the deprecated
    valueselector - hide the non implemented statistics option - turn
    the data mode selector to an on/off switch, ofono supports only
    those.

  [ Iain Lane ]
  * Use GLib to get the sizes of directories to display in
    Storage>About, displaying a spinner while the information is being
    calculated. Also record the total space used by click packages to
    display too. (LP: #1205297, #1228419)

  [ Łukasz 'sil2100' Zemczak ]
  * In a hacky way, try hiding the welcome-screen background changing
    elements for v1 - by a design decision. (LP: #1230295)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 401
 -- Ubuntu daily release <email address hidden> Mon, 30 Sep 2013 09:37:44 +0000

Manuel wrote this proof-of-concept for unmarshalling an array-of-dicts, e.g. aa{ss} in Qt:

http://bazaar.launchpad.net/~mandel/+junk/send-array-dicts/files

Hi guys, any progress on this bug? I'd like to get the system-image changes in for version 2.0, if the u/i is ready to handle it.

Moving back to Triaged and de-milestoning until I hear from the u/i guys that they're ready for this.

At this point, I'm going to demote this to a wish list item. There seems to be no urgency in providing this feature.

I just took a quick peek to see if this is something we could support. I'm confused though; enabling the signal in s-i-dbus gives this kind of UpdateAvailableStatus:

signal sender=:1.79 -> dest=(null destination) serial=67 path=/Service; interface=com.canonical.SystemImage; membe
r=UpdateAvailableStatus
   boolean true
   boolean true
   string "41"
   int32 153477688
   string "2014-05-16 09:48:27"
   array [
      array [
         dict entry(
            string "description"
            string "ubuntu=20140516.3,device=20140513.2,version=33"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140516.4,device=20140513.2,version=34"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140517,device=20140513.2,version=35"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140518,device=20140513.2,version=36"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140519,device=20140513.2,version=37"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140519.1,device=20140513.2,version=38"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140520,device=20140513.2,version=39"
         )
      ]
      array [
         dict entry(
            string "description"
            string "ubuntu=20140521,device=20140513.2,version=41"
         )
      ]
   ]
   string ""

what are we supposed to do with those descriptions? Perhaps this means that the
server isn't providing what we want yet?

On May 21, 2014, at 09:22 AM, Iain Lane wrote:

>what are we supposed to do with those descriptions? Perhaps this means that
>the server isn't providing what we want yet?

At one time, the server was going to give i18n'd human readable descriptions.
I don't know whether the current behavior is because the ui couldn't do
anything with them, or whether the information is not available when the
server crafts the index.json files. If the i18n descriptions won't be
available on the server, then it seems pointless to want to expose i18n
descriptions in the API and ui. If that's the case, let's close this bug as
won't fix. Stephane?

On Wed, May 21, 2014 at 09:34:08AM -0400, Barry Warsaw wrote:
> On May 21, 2014, at 09:22 AM, Iain Lane wrote:
>
> >what are we supposed to do with those descriptions? Perhaps this means that
> >the server isn't providing what we want yet?
>
> At one time, the server was going to give i18n'd human readable descriptions.
> I don't know whether the current behavior is because the ui couldn't do
> anything with them, or whether the information is not available when the
> server crafts the index.json files. If the i18n descriptions won't be
> available on the server, then it seems pointless to want to expose i18n
> descriptions in the API and ui. If that's the case, let's close this bug as
> won't fix. Stephane?

So far we've never bothered write those descriptions (I just put the
channel info in the description at the moment) or get any of that
translated, but I'd expect that when we hit RTM we'll be asked to do it.

Pushing updates to end users without a localized description is IMO
unacceptable, so this feature is still going to be required down the
line.

--
Stéphane Graber
Ubuntu developer
http://www.canonical.com

On Wed, May 21, 2014 at 02:48:44PM -0000, Stéphane Graber wrote:
> On Wed, May 21, 2014 at 09:34:08AM -0400, Barry Warsaw wrote:
> > On May 21, 2014, at 09:22 AM, Iain Lane wrote:
> >
> > >what are we supposed to do with those descriptions? Perhaps this means that
> > >the server isn't providing what we want yet?
> >
> > At one time, the server was going to give i18n'd human readable descriptions.
> > I don't know whether the current behavior is because the ui couldn't do
> > anything with them, or whether the information is not available when the
> > server crafts the index.json files. If the i18n descriptions won't be
> > available on the server, then it seems pointless to want to expose i18n
> > descriptions in the API and ui. If that's the case, let's close this bug as
> > won't fix. Stephane?
>
> So far we've never bothered write those descriptions (I just put the
> channel info in the description at the moment) or get any of that
> translated, but I'd expect that when we hit RTM we'll be asked to do it.
>
>
> Pushing updates to end users without a localized description is IMO
> unacceptable, so this feature is still going to be required down the
> line.

So that we can implement this, could you put some dummy information in
there? It can be just lorem ipsum in a few languages (not actually
translated), but it'll be enough to write the user interface and then we
can actually display it when it is provided properly.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

At this point, any change we want to make here will require a new D-Bus API as it would be a compatibility break. I'm going to remove the commented out code and update the D-Bus API docs to reflect this, but I'll leave this bug open in case we ever want to re-enable this feature.

Does anybody still care about this? I'm tempted to just abandon the branch and close the bug. At this point we'd have to treat it as a new feature anyway. Speak now or hold your peace :)