Not possible for other docks to use Unity LauncherAPI

[Matias Särs]

When the launcher API was reported people questioned why unity wouldn't use DockManager. The answer that was given was that unity launcher API was better. It's easier for developers use unity launcher api within their own applications. As a dock developer I agreed and welcomed unity launcher api, it sounded like a good idea and something I would like to implement in my dock. When I started looking in to it the disappointment hit me: libunity requires Unity to be running (or more exactly it requires the unique d-bus address com.canonical.Unity to be in use) otherwise it doesn't send out any signals over dbus. I can hack my way around this by letting my dock register the com.canonical.Unity address but that's not an ideal solution. What will happen then if the user tries to start unity while my dock is running?

[Robert Dyer (psybers)]

Since the unity team came up with their own API instead of using DockManager, and due to the pushing of it by Canonical and thus lots of apps adopting that API (in favor of DockManager), Michal Hruby and I decided to just stop supporting DockManager. Thus, all docks will (most likely) start supporting the unity API instead.

So this bug will now affect any dock that might support that: DockbarX, AWN, Docky, Plank, etc.

The poster's hack seems reasonable (as a hack), in that it is probably rare that users would want to run more than one dock at the same time. But hopefully there is a better solution.

[Mikkel Kamstrup Erlandsen (kamstrup)]

@Matias: I can appreciate your frustration. I think it was mostly because of my criticism of the Dockmanager API that we didn't use it (so pitchforks in my general direction ;-)).

As the FAQ on https://wiki.ubuntu.com/Unity/LauncherAPI also explains I think the Dockmanager API is actively bad (sorry to be frank). We've seen a great many times (and I shall omit finger pointing) that thrashing DBus is a *very* bad thing to do. It affects app responsiveness and startup times (very) noticeably.

But since we did (an do) need an API to talk o the launcher Neil and I quickly threw something together that would minimize the bus traffic while exposing only the minimal feature set that we wanted. And let me emphasize that this was how this DBus protocol was created - minimal and in haste. Hence the fat disclaimer in the description of it: "While the libunity is unstable, the DBus protocol underneath is even more so. We strongly discourage anyone from relying on it".

My emphasis on minimizing bus traffic also explains why we check whether Unity is running before emitting property changes: it's to minimize chatter on the bus when Unity starts. Unity relies heavily on DBus and if we had 20 processes all fighting to set launcher states on startup this could easily add a second or so to the startup time. Sure - one could device a more clever protocol that could implement this optimization without depending explicitly on the com.canonical.Unity name, but as said we were in a rush to get this out so the simplest option was taken.

To answer you last question Matias: the answer is "nothing would happen, everything would continue to work". Either Unity fails to start because it can't own the name - or it steals the name from your dock. But all of this doesn't matter to libunity as it only cares whether *anyone* owns the com.canonical.Unity name. And since the Update() message is a signal broadcast on the bus anyone (including 3rd party docks that ignores the disclaimer from the FAQ) can still listen to it.

Phew long post. Hope it explains the state of things.

PS: And let me add - no one on the Unity team desires the Launcher API/protocol to be a private thing necessarily. But we do care a great deal that it's an d API that behaves exactly like we need it to. So if someone comes up with and even better API (or want to design one) that works for all docks and launchers out there we are open to talk business :-)

[Mikkel Kamstrup Erlandsen (kamstrup)]

@Robert: I hope my previous comment to Matias also sheds some light on the matter for you. If you have further questions don't hesitate to follow up or ping me, kamstrup, on #ayatana.

[Matias Särs (msevens)]

@Mikkel
I really like the way unity API is designed and do agree that it's better than dockmanager. Except for the need of this hack it was a quite pleasant excerice to implement it in DockbarX. As long as the dialog is with other dock developers is kept open I think it's great.

DockbarX is right now taking over com.canonical.Unity if unity is not running and it works fine except for Chromium/chrome users. Chromium also uses com.canonical.Unity to check wheter unity is running and removes maximize/minimize/close buttons if it does.

Would it be possible for libunity to check not only for com.canonical.Unity but also for another unique address that other docks could use? If that address is used only for this purpose any dock could own it without any side effects. One other address is enough since - as you mentioned - it doesn't matter who owns it as long as it is owned by someone.

[Robert Dyer (psybers)]

Yes perhaps just look for a 'com.canonical.LibUnity' or something similar. Of course, Unity would have to be updated to provide this address (in addition to what it already does).

[Omer Akram (om26er)]

In case something gets missed here ~ayatana-dev list might be a better
place for this discussion and enhancement.

On Tue, Sep 6, 2011 at 2:00 PM, Robert Dyer <email address hidden> wrote:
> Yes perhaps just look for a 'com.canonical.LibUnity' or something
> similar.  Of course, Unity would have to be updated to provide this
> address (in addition to what it already does).
>
> --
> You received this bug notification because you are subscribed to unity.
> Matching subscriptions: my-unity-2d-bugs
> https://bugs.launchpad.net/bugs/811826
>
> Title:
>  Not possible for other docks to use Unity LauncherAPI
>
> Status in LibUnity:
>  New
> Status in Unity:
>  New
> Status in Unity 2D:
>  Invalid
> Status in “libunity” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  When the launcher API was reported people questioned why unity
>  wouldn't use DockManager. The answer that was given was that unity
>  launcher API was better. It's easier for developers use unity launcher
>  api within their own applications. As a dock developer I agreed and
>  welcomed unity launcher api, it sounded like a good idea and something
>  I would like to implement in my dock. When I started looking in to it
>  the disappointment hit me: libunity requires Unity to be running (or
>  more exactly it requires the unique d-bus address com.canonical.Unity
>  to be in use) otherwise it doesn't send out any signals over dbus. I
>  can hack my way around this by letting my dock register the
>  com.canonical.Unity address but that's not an ideal solution. What
>  will happen then if the user tries to start unity while my dock is
>  running?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/libunity/+bug/811826/+subscriptions
>

[Alex Baggott (alex-baggott)]

As part of the big bug review for 16.04 LTS, I think this is a feature request rather than a bug.