Merge lp://qastaging/~muktupavels/libappindicator/create-as-service into lp://qastaging/libappindicator/15.10

Unfortunately it fails to build because NOTIFICATION_ITEM_DBUS_OBJ is not defined:
http://mitya57.me/builds/libappindicator_12.10.1+15.04.20141110-0ubuntu2_amd64.build

> Unfortunately it fails to build because NOTIFICATION_ITEM_DBUS_OBJ is not
> defined:
> http://mitya57.me/builds/libappindicator_12.10.1+15.04.20141110-0ubuntu2_amd64
> .build

Previous commit was missing one file... I hope that now it builds.

Thanks! It builds now. I tested with remmina and transmission, everything seems to work as before.

I'm a little confused, why do we want Items to register a name on the bus? I'm not sure what benefit that has, and it makes things more difficult when we start looking at application confinement where we're not allowing name registrations.

> I'm a little confused, why do we want Items to register a name on the bus? I'm

Because it is what spec says, no?

http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierWatcher/
"Register a StatusNotifierItem into the StatusNotifierWatcher, in the form of its full name on the session bus, for instance org.freedesktop.StatusNotifierItem-4077-1."

> not sure what benefit that has, and it makes things more difficult when we
> start looking at application confinement where we're not allowing name
> registrations.

For example it makes easier to watch when name (status notifier item) disappears from bus:
https://github.com/albertsmuktupavels/libstatus-notifier/blob/master/libstatus-notifier/sn-watcher.c#L117

Did not understand part about not allowing name registrations... :(

On Tue, 2015-06-30 at 14:18 +0000, Alberts Muktupāvels wrote:

> > I'm a little confused, why do we want Items to register a name on the bus? I'm
>
> Because it is what spec says, no?
>
> http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierWatcher/
> "Register a StatusNotifierItem into the StatusNotifierWatcher, in the form of its full name on the session bus, for instance org.freedesktop.StatusNotifierItem-4077-1."

Ah, interesting. That's been added since we implemented the spec.

> > not sure what benefit that has, and it makes things more difficult when we
> > start looking at application confinement where we're not allowing name
> > registrations.
>
> For example it makes easier to watch when name (status notifier item) disappears from bus:
> https://github.com/albertsmuktupavels/libstatus-notifier/blob/master/libstatus-notifier/sn-watcher.c#L117

You can watch for when the connection drops off the bus as well. I don't
think there's a real difference between watching the name and the
connection.

> Did not understand part about not allowing name registrations... :(

For Ubuntu Personal and Ubuntu Phone we want to allow application
indicators in the convergence cases, but the confinement there doesn't
allow for name registrations on the dbus session bus.

> On Tue, 2015-06-30 at 14:18 +0000, Alberts Muktupāvels wrote:
>
> > > I'm a little confused, why do we want Items to register a name on the bus?
> I'm
> >
> > Because it is what spec says, no?
> >
> > http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNoti
> fierWatcher/
> > "Register a StatusNotifierItem into the StatusNotifierWatcher, in the form
> of its full name on the session bus, for instance
> org.freedesktop.StatusNotifierItem-4077-1."
>
>
> Ah, interesting. That's been added since we implemented the spec.

I don't like this spec, but I guess there is no better choice... Does that mean that they have changed spec when there was existing implementations?

> > > not sure what benefit that has, and it makes things more difficult when we
> > > start looking at application confinement where we're not allowing name
> > > registrations.
> >
> > For example it makes easier to watch when name (status notifier item)
> disappears from bus:
> > https://github.com/albertsmuktupavels/libstatus-notifier/blob/master
> /libstatus-notifier/sn-watcher.c#L117
>
>
>
> You can watch for when the connection drops off the bus as well. I don't
> think there's a real difference between watching the name and the
> connection.

That was just small example. Still I think it is better to follow spec not trying to support each possible implementation that is different from spec.

> > Did not understand part about not allowing name registrations... :(
>
>
> For Ubuntu Personal and Ubuntu Phone we want to allow application
> indicators in the convergence cases, but the confinement there doesn't
> allow for name registrations on the dbus session bus.

Is there a way to detect that application is running on Ubuntu Personal and/or Ubuntu Phone? Then I could update branch to register dbus name only if it is not running on Personal or Phone.

On Wed, 2015-07-01 at 16:32 +0000, Alberts Muktupāvels wrote:

> I don't like this spec, but I guess there is no better choice... Does
> that mean that they have changed spec when there was existing
> implementations?

Yes, and I imagine that is why it is written as a "can" instead of a
"must" or even "should."

"Each application can register"

http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/

> > You can watch for when the connection drops off the bus as well. I don't
> > think there's a real difference between watching the name and the
> > connection.
>
>
> That was just small example. Still I think it is better to follow spec
> not trying to support each possible implementation that is different
> from spec.

Since it is not a required part of the spec I think you should probably
support the more generic DBus mechanisms as well as parts of the spec
that you wish.

> > > Did not understand part about not allowing name registrations... :(
> >
> >
> > For Ubuntu Personal and Ubuntu Phone we want to allow application
> > indicators in the convergence cases, but the confinement there doesn't
> > allow for name registrations on the dbus session bus.
>
>
> Is there a way to detect that application is running on Ubuntu
> Personal and/or Ubuntu Phone? Then I could update branch to register
> dbus name only if it is not running on Personal or Phone.

I think what would perhaps be better is allow for the name registration
to fail, and handle that exception. There's no real reason to put the
name in the messages. Basically make it so that the name request is only
optional to have succeed.

> On Wed, 2015-07-01 at 16:32 +0000, Alberts Muktupāvels wrote:
>
> > I don't like this spec, but I guess there is no better choice... Does
> > that mean that they have changed spec when there was existing
> > implementations?
>
>
>
> Yes, and I imagine that is why it is written as a "can" instead of a
> "must" or even "should."
>
> "Each application can register"
>
> http://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifi
> erItem/

I understand it like this:
Each application can register multiple items...

Next paragraph:
"As soon as a new instance of a StatusNotifierItem is created, the application must register the unique instance name to the StatusNotifierWatcher as described in the Section called StatusNotifierWatcher"

Is not unique name meant to be org.freedesktop.StatusNotifierItem-PID-ID?

RegisterStatusINotifierItem method:
"Register a StatusNotifierItem into the StatusNotifierWatcher, in the form of its full name on the session bus, for instance org.freedesktop.StatusNotifierItem-4077-1."

> > > You can watch for when the connection drops off the bus as well. I don't
> > > think there's a real difference between watching the name and the
> > > connection.
> >
> >
> > That was just small example. Still I think it is better to follow spec
> > not trying to support each possible implementation that is different
> > from spec.
>
>
>
> Since it is not a required part of the spec I think you should probably
> support the more generic DBus mechanisms as well as parts of the spec
> that you wish.

Well spec says exactly how item should be registered with watcher... I don't know how that spec looked in past - that is what I am reading right now.

> > > > Did not understand part about not allowing name registrations... :(
> > >
> > >
> > > For Ubuntu Personal and Ubuntu Phone we want to allow application
> > > indicators in the convergence cases, but the confinement there doesn't
> > > allow for name registrations on the dbus session bus.
> >
> >
> > Is there a way to detect that application is running on Ubuntu
> > Personal and/or Ubuntu Phone? Then I could update branch to register
> > dbus name only if it is not running on Personal or Phone.
>
>
> I think what would perhaps be better is allow for the name registration
> to fail, and handle that exception. There's no real reason to put the
> name in the messages. Basically make it so that the name request is only
> optional to have succeed.

https://developer.gnome.org/gio/stable/gio-Owning-Bus-Names.html#g-bus-own-name
That would be name_lost_handler with connection == NULL, right?

So, are you ok with this change? with adding fallback to old behaviour if name registration fails?

On Wed, 2015-07-01 at 20:58 +0000, Alberts Muktupāvels wrote:

> I understand it like this:
> Each application can register multiple items...
>
> Next paragraph:
> "As soon as a new instance of a StatusNotifierItem is created, the application must register the unique instance name to the StatusNotifierWatcher as described in the Section called StatusNotifierWatcher"
>
> Is not unique name meant to be org.freedesktop.StatusNotifierItem-PID-ID?

No, it is not. A unique bus name is the name that DBus gives the
connection, for example :3.0. You can find a description of the various
bus names in the DBus spec:

http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus

There can only be one item per connection because even if you registered
for another name SNI hardcodes the object path, and you only get one of
those per connection. (something I'm not fond of in the spec, but eh)

> https://developer.gnome.org/gio/stable/gio-Owning-Bus-Names.html#g-bus-own-name
> That would be name_lost_handler with connection == NULL, right?

It would be a call to name_lost_handler, but the connection would be
valid as there was the ability to connect to the bus.

> So, are you ok with this change? with adding fallback to old behaviour if name registration fails?

Yes, as long as we don't have the requirement to get the name I'm find
with asking for it.