Need to provide an api for setting launcher counters

[Michał Sawicz]

For reference, old API: https://wiki.ubuntu.com/Unity/LauncherAPI#Count

My proposal is, on dbus:

/com/canonical/Unity/Launcher
com.canonical.Unity.Launcher.SetCounter(string app_id, int count, bool visible)

This will obviously need to be wrapped in a lib later, possibly even platform api, and ideally the old libunity api will be ported to support this, too.

Short-term the above interface called by push notification daemon should be enough.

[John Lenton (chipaca)]

May I propose that we make it

int IncreaseCounter(app_id, delta, visible)

that increases the counter by the (signed) delta, and returns the current (post-delta) value?

[Michał Sawicz (saviq)]

Maybe we need both... Like GMail will know how many emails you've got unread, not how many push notifications actually reached the device, or whether the app changed it to something completely different...

What would be the use case do you think of incrementing? Where would you not know the complete value in the first place?

[Ted Gould (ted)]

It would probably be better to make the path have the appid in it so that we can let confined apps set their own and not others using the apparmor profile. So I'd suggest:

/com/canonical/Unity/Launcher/$(appid)
com.canonical.Unity.Launcher.SetCounter(int count, bool visible)

Or alternatively two properties on that object, Count and CountVisible.

[Michał Sawicz (saviq)]

On 02.04.2014 20:51, Ted Gould wrote:
> /com/canonical/Unity/Launcher/$(appid)
> com.canonical.Unity.Launcher.SetCounter(int count, bool visible)

That'd mean we have to register that for every app, right? Feels rather
dangerous if we end up using the same for in-dash emblems, where all
installed apps will be - and all those objects would have to be
registered, too...

> Or alternatively two properties on that object, Count and CountVisible.

Maybe a prop would work indeed, would mean a little bit more dbus
traffic, but this is probably a low enough traffic api that'd be fine.

[Ted Gould (ted)]

On Wed, 2014-04-02 at 22:26 +0000, Michał Sawicz wrote:

> On 02.04.2014 20:51, Ted Gould wrote:
> > /com/canonical/Unity/Launcher/$(appid)
> > com.canonical.Unity.Launcher.SetCounter(int count, bool visible)
>
> That'd mean we have to register that for every app, right? Feels rather
> dangerous if we end up using the same for in-dash emblems, where all
> installed apps will be - and all those objects would have to be
> registered, too...

You don't have to register anything on DBus, just respond to that path.
You can set up a fallback path for the items that are not currently in
memory to just write them in settings until needed.

> > Or alternatively two properties on that object, Count and
> CountVisible.
>
> Maybe a prop would work indeed, would mean a little bit more dbus
> traffic, but this is probably a low enough traffic api that'd be fine.

Props are nice because you get the getter/setter/notification for "free"
in that you don't have to define the API for them. It can be lower
traffic because of the GetAll command if someone is querying the
interface and there are several properties they may need.

[Michał Sawicz (saviq)]

OK, that sounds good for me, if we can have a "catch-all" interface like that, I'm game. +1 on props, too.

[David Barth (dbarth)]

Rather -1 on the idea of having the increment API: it feels like a new source of bugs and user confusion if when the counters get out of sync.

[Michał Sawicz (saviq)]

On 08.04.2014 11:05, David Barth wrote:
> Rather -1 on the idea of having the increment API: it feels like a new
> source of bugs and user confusion if when the counters get out of sync.

I probably agree, whatever puts the counter on the launcher should
probably have all info to determine the full number anyway...

[Ted Gould (ted)]

Adding a bug task for easyprof-ubuntu to add the path to the allowed paths for an app to be able to set its own count.

[Jamie Strandboge (jdstrand)]

Per discussion on irc, all apps should now have this access:
  dbus bus=session path=/com/canonical/unity/launcher/@{APP_ID_DBUS},

This will be added in the next apparmor-easyprof-ubuntu upload.

[Jamie Strandboge (jdstrand)]

This will be in apparmor-easyprof-ubuntu 1.1.17 which is in silo 17 with the media-hub update.

[Launchpad Janitor (janitor)]

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.1.17

---------------
apparmor-easyprof-ubuntu (1.1.17) utopic; urgency=medium

  * 1.*/audio,video: allow communications with the media-hub-server now that
    it is a trusted helper (LP: #1303962)
  * 1.1/music_files*,video_files*: revert media-hub rules in 1.1.15 now that
    common policy groups (audio and video) can be used instead
  * 1.1/ubuntu-*: allow apps to communicate with the Launcher via their
    @{APP_ID_DBUS} specific path (LP: #1301400)
 -- Jamie Strandboge <email address hidden> Wed, 16 Apr 2014 13:40:03 -0500

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity8 - 7.86+14.10.20140505-0ubuntu1

---------------
unity8 (7.86+14.10.20140505-0ubuntu1) utopic; urgency=low

  [ Ted Gould ]
  * Provide a dbus interface for setting the count and countVisible
    properties. (LP: #1301400)

  [ Michał Sawicz ]
  * Pass env variables to initctl start.
  * Suffix .sh to our scripts and clean up debian/rules.
  * Adapt to Debian Qt package renames and drop unneeded Dee plugin
    dependency.

  [ Ying-Chun Liu ]
  * Add Zoomable Image for Preview widgets.

  [ Albert Astals ]
  * Remove support for Qt <= 5.2.1

  [ Mirco Müller ]
  * Implemented feature-request from Design for modal snap-decision
    notifications on the phone. See LP #1285712 (LP: #1285712)

  [ Andrea Cimitan ]
  * Make progressbas in preview widget big as the button

  [ CI bot ]
  * Resync trunk
 -- Ubuntu daily release <email address hidden> Mon, 05 May 2014 12:09:43 +0000