Web lists-archives.com

Re: Upcoming shift to Ayatana (App)Indicator(s)

Hi Simon,

On  Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:

On Thu, 29 Mar 2018 at 13:11:54 +0000, Mike Gabriel wrote:
This is to make people aware and inform about an ongoing effort to replace
Indicators in Debian (most people know the concept from Ubuntu) by a more
generically developed and actively maintained fork: Ayatana Indicators.

Which concrete libraries and packages does this refer to? As a
Debian/GNOME contributor who has not been involved in Ubuntu or Ayatana,
I've been confused in the past about what the difference is between
libindicate, libindicator, libappindicator and possibly others.

The maintained src:packages in Debian currently are:

  libayatana-appindicator (needed for SNI client applications)
    closely related lib: libdbusmenu

  The AppIndicator shared lib from Ubuntu is widely used in Debian,
  see https://wiki.debian.org/Ayatana/IndicatorsTransition

  ayatana-ido (both needed for indicator renderers)

  The Indicator/IDO shared libs from Ubuntu are not used much anymore
  in Debian:

    ido -> budgie-indicator-applet (see #893707 [1])
    libindicator -> all applications that build against libappindicator
                    from Ubuntu, unfortunately
      plus directly: cairo-dock-alsamixer-plug-in

  The system indicators (indicator icons with system control functionality):

    where "*" can be:

      notifications (NEW)
      messages (NEW)
      sound (in prep)
      datetime (in prep)
      keyboard (in prep)

  Their Ubuntu pendants are not in unstable anymore (indicator-* by name)
  or have never made it there.

  libindicate(-qt): totally deprecated, even in Ubuntu AFAICT. It has
  only been used in indicator-messages (libmessaging-menu) and got replaced
  by a GMenu based approach.
  See [2].

It would be great to have a tl;dr road map for these libraries, and any
related libraries that are in NEW or otherwise not in Debian yet,
classifying them into:

* current and recommended (preferably documented by an upload)

Done. See above.

* deprecated but still supported (preferably documented by an upload
  and/or ftp.debian.org bug overriding their Section to oldlibs)

I can do that after Easter. Note taken.

* unsupported and should not be in Debian (preferably documented
  by RC bugs "should not be released with buster" and/or ftp.debian.org
  RM bugs)

Will do that for libindicate and libindicate-qt (also after Easter) and possibly also for ido src:package.

Theses are panel plugins mostly, that render the system tray icons and menus
(and widgets) defined by indicator aware applications. They normally come
with your desktop environment (if it supports indicators).

Am I right in thinking that Ubuntu's
https://github.com/Ubuntu/gnome-shell-extension-appindicator is the
recommended implementation of this for GNOME 3?

Yes and no. While it brings application indicators back to GNOMEv3 (what we do for GTK-3 applications with libayatana-appindicator), it does not show system indicators icons' at all. This is non-problematic for GNOME because the model for user interaction with the system controls has been re-done in GNOMEv3 with a different concept.

The nice part of Ayatana AppIndicator shared library is: if a desktop  shell
does not offer the SNI service, then it tries to fall back to the xembed-way
of adding system tray icons to your panel / status bar.

Is Ayatana AppIndicator a reasonable exit strategy for escaping from
XEmbed-based tray icons, which are increasingly poorly supported and have
no Wayland implementation?

Yes, absolutely! And, it allows one to have more fiddly widgets in those system tray menus then, too (like sliders, calendars, switches, etc.).

I currently maintain gnome-shell-extension-top-icons-plus, and would be
happy to hand it over to someone else or deprecate it in favour of a
different "tray icon" mechanism (or even make it a transitional package
if some new extension can be made to act as a drop-in replacement).

Oh, please keep that maintained. While AppIndicator is already widely spread, there are still many applications or even widget tool kits out there, that only have xembed support (e.g. wxWidgets afaik). Dropping xembed support from GNOMEv3 would be painful to users of these applications.

We have a ayatana-indicator-systemtray in prep that catches such xembed applications and proxies them trough to an indicator renderer. However, ayatana-indicator-systemtray will be a system indicator (not an application indicator, thus not using SNI). For GNOMEv3 this means, it won't be available there.

This xembed to SNI (StatusNotifier DBus Interface, also termed AppIndicator) is a slightly different cup of tea than the above addressed transition from Ubuntu Indicators to Ayatana Indicators. However, it is a highly valid one. But it requires application developers to reimplement their code based on xembed and switch to an SNI capable approach (where Ayatana AppIndicator is just one of them, the Qt5 people have their own approach for that).


Thanks for your questions!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893707
[2] https://github.com/AyatanaIndicators/ayatana-indicator-messages/commit/e1c600ba95e4520caf471ebf2eb9f41e2580fa98


mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabriel@xxxxxxxxxxxxxxxxxxx, http://das-netzwerkteam.de

Attachment: pgpoIry_vnjeP.pgp
Description: Digitale PGP-Signatur