Making appindicators available for non-Ubuntu platforms

As many (Debianic) people possibly know, the appindicator support (libindicator, libappindicator, etc.) in Debian is very weak and outdated. Various native indicators (e.g. indicator-* packages , where * is "datetime", "sound", "session", etc.) are missing or unmaintained in Debian and neither is the indicator-application service available (a service that allows other applications e.g., like the nm-applet tool to dock to the indicator area of the desktop's panel bar). Furthermore, no recent appindicator related uploads have been seen in Debian (last seen uploads are from 2013).

I recently e-mailed with Andrew Starr-Bochicchio, one of the Ayatana Packaging team members, about the current Debian status of indicator packages specifically and Ayatana packages [1] in general. The below information summarizes (I hope) what I got from the mail exchange:

The reason for the currently somehow orphaned package situation around Ayatana originated [2] packages (appindicator support being among those packages) in Debian is that the Ayatana packaging team in Debian started working on porting Ubuntu's upstream projects to Debian some time around the Ubuntu lucid cycle, when Ubuntu was still installing GNOMEv2 as the default desktop environment. The original goal was to bring Ubuntu's GNOMEv2 improvements to Debian. Various things have changed since then (Ubuntu moved on to Unity as default desktop environment, the Ubuntu phone and desktop convergence is about to happen, etc.). The appindicator packages in Debian should actually be orphaned, because they are virtually unmaintained.

Why spending time on appindicators?

In the context of the Arctica Project I have recently forked Unity Greeter under the name Arctica Greeter. Arctica Greeter will be one tool for launching local and remote desktop sessions on Arctica's thin client machines. The current version of Unity Greeter ships some great code for handling remote session startup, that we would like to use in the Arctica Project, be it on Ubuntu machines or some other platform.

We already have binaries of Arctica Greeter that work well under the LightDM display manager, they can be installed via the nightly builds repository of the Arctica Project [2]:

root@stretch-host:~# apt-get install arctica-greeter

However, gaining full functionality in Arctica Greeter (like people have gotten used to from Ubuntu's Unity Greeter) requires Ubuntu's appindicator framework to be fully available on machines that Arctica Greeter is installed on.

Forking appindicator related code? Yes!

After receiving all the background information about the Ayatana packaging status in Debian, I contacted Martin Wimpress (currently Mr. Ubuntu MATE, I'd say). We agreed that appindicator support in desktop environments is something nice to have and that the original idea behind appindicators is great. The desktop appearance in Ubuntu MATE greatly increases in spreading its charme when appindicator support is enabled during the Ubuntu MATE installation.

However, the indicator code in Ubuntu hasn't see many changes either, recently (most changes go back to Ubuntu 12.10). The code is there and it works. On Ubuntu, that is. During my discussion with Martin, I came to the conclusion to look at the various appindicator code projects more closely and consider forking them with the goals of:

  1. Making appindicators more generic, so that all Linux distribution can use the framework without heavy patching at packaging time.
  2. Dropping all hints to the com.canonical.indicator namespace in DBus configurations and replacing such occurrences with org.ayatana.indicator namespace.
  3. Dropping all hints to "(U|u)(N|n)(I|i)(T|t)(Y|y)" in path names and variables and replacing them by some similar capitalization of the word Ayatana
  4. Making the forks co-install just fine with Ubuntu's appindicator packages when installing on Ubuntu
  5. Making appindicators and esp. the various indicator applets independent from Ubuntu-only aspects / implementations: upstart, click package format/system, Mir, etc.
  6. Providing a DBus proxy service that can pipe indicator implementations trying to connect to com.canonical.indicator.application.service through to our non-Ubuntu indicator application service implementation (listening on org.ayatana.indicator.application.service).

Work has already started...

The first two libraries (ayatana-ido [4] and libayatana-indicator [5]) have already been forked. Next todos on the list are: libayatana-appindicator and ayatana-indicator-application.

Unfortunately, the Ubuntu upstream projects are heavily entangled with each other. The indicator applets, for example, heavily make use of the URL dispatcher service in Ubuntu (which is not available in non-Ubuntu Linux distros, either). I will check what makes sense here (dropping URL dispatcher support, forking URL dispatcher, providing packaging recipes for URL dispatcher with an appropriate patchset, etc.).

At the end of the day, this might actually end up in a non-Ubuntu centred Ayatana Inheritence Project. Continue code started by Canonical, but finally discontinued during the course of variuous strategy changes in the development of the Ubuntu Phone and Desktop operating system, mainly governed by Canonical Ltd. As Martin Wimpress said: ,,I expect a lot of forks to happen in the near future...''.

Current Plans and Future Thoughts...

At the time being, I only fork the code required for getting Arctica Greeter running on non-Ubuntu systems and the forked code will be hosted on, but in the long run it may become more appropriate to set up its own project for the purpose of continuing / generalizing Ubuntu-only code and making it more usable on non-Ubuntu systems. I don't think that this effort is doable on the package maintainer level. I originally thought that it would be, but I finally reached the conclusion that it is not. The endeavour must be approached with the mentality of people being the new upstream developers of Ayatana-originated code.