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:
1.
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
2.
libayatana-indicator
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
cairo-dock-messaging-menu-plug-in
lightdm-gtk-greeter
workrave
3.
The system indicators (indicator icons with system control functionality):
ayatana-indicator-*
where "*" can be:
session
power
printers
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.
4.
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).
smcv
Thanks for your questions! Mike [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893707[2] https://github.com/AyatanaIndicators/ayatana-indicator-messages/commit/e1c600ba95e4520caf471ebf2eb9f41e2580fa98
-- DAS-NETZWERKTEAM 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@das-netzwerkteam.de, http://das-netzwerkteam.de
Attachment:
pgp3igyKqPtN2.pgp
Description: Digitale PGP-Signatur