Re: Upcoming shift to Ayatana (App)Indicator(s)
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.
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)
* deprecated but still supported (preferably documented by an upload
and/or ftp.debian.org bug overriding their Section to oldlibs)
* 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)
> 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?
> 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?
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).
smcv
Reply to: