Re: Upcoming shift to Ayatana (App)Indicator(s)
- Date: Fri, 30 Mar 2018 00:29:01 +0100
- From: Simon McVittie <smcv@xxxxxxxxxx>
- Subject: Re: Upcoming shift to Ayatana (App)Indicator(s)
On Thu, 29 Mar 2018 at 21:19:35 +0000, Mike Gabriel wrote:
> On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
> > 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:
Rephrasing to check whether I understand, is this a correct summary of
libraries to which an indicator client might be linked, from a Debian
maintained fork of libindicator, recommended for indicator renderers
(the indicator equivalent of the freedesktop.org/X11 notification area) and
maybe StatusNotifierItem client apps (apps with the indicator equivalent
of a GtkStatusIcon)
maintained fork of libappindicator, recommended for SNI client apps
dependency of lib(ayatana-)?appindicator and libindicate
deprecated library for both indicator renderers and SNI client apps;
replace with libayatana-indicator (requires little or no porting?); orphaned
deprecated library for SNI client apps; replace with libayatana-appindicator
(requires little or no porting?); orphaned
src:libindicate (libindicate5, libindicate-gtk*):
deprecated^2 library for SNI client apps; replace with
libayatana-appindicator (requires non-trivial porting); orphaned, should
... and many of those have both GTK+ 2 and GTK+ 3 flavours, and sometimes
a separate GUI-agnostic shared library for D-Bus protocols.
I hope you can see why I was confused by all the
lib(ayatana-)?(app)?indicat(e|or)((-gtk)?3)? libraries involved in this!
If libayatana-appindicator and libayatana-indicator require no
source-level porting from their non-Ayatana counterparts (same symbols,
different SONAME), perhaps we could have transitional packages containing
appropriate symlinks, rather than carrying around the orphaned libraries
from which they were forked?
(I'm more interested in SNI client apps here, and less interested in
indicator renderers, because a random Debian developer is more likely
to maintain a SNI client app than to maintain a renderer, so that seems
like the side where it's particularly important to have a clear picture
of what you should and shouldn't be depending on.)
> > 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.
Again, what I'm mostly interested in here is the sort of random apps
that used to use the freedesktop.org/X11 status notifier protocol
to have a "tray icon", like Steam or Pidgin, because those are
the ones that need more cross-distribution coordination. Is your
intended future that they would have an application indicator that
serves more or less the same purpose, GNOME 3 would display those via
gnome-shell-extension-appindicator, and non-GNOME environments would
display those icons alongside the environment's system-level indicators
like networking or Bluetooth or similar?
> > 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.
I'll try, but it's no longer maintained upstream, and very dependent
on GNOME Shell not dropping XEmbed support completely. I don't have the
necessary knowledge or bandwidth to become its upstream maintainer.