[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Hi Simon,

On  Fr 30 Mär 2018 01:29:01 CEST, Simon McVittie wrote:


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
perspective?


Rephrasing is good. Thanks.


src:libayatana-indicator (libayatana-indicator(3-)?7):
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)
Yes. Correct. Supplemented by an extra-fancy-widgets library called "ayatana-ido" (src:pkg) forked from Ubuntu's "ido" (indicator display objects). 


src:libayatana-appindicator (libayatana-appindicator(3-)?1):
maintained fork of libappindicator, recommended for SNI client apps
GTK-3 SNI applications, yes. In Qt5, there must be something similar. Natively in Qt5, I guess. I should know more about this. Maybe someone with Qt5 insights can provide additional info. 


src:libdbusmenu:
dependency of lib(ayatana-)?appindicator and libindicate


Yes, it provides an API for sending menu structures over a DBus interface.
Side note: Please forget libindicate, it is about to be dead. It was used to send new-message-notifications between applications and the indicator-messages system indicator. Handles otherwise nowadays. 


src:libindicator (libindicator(3-)?7):
deprecated library for both indicator renderers and SNI client apps;
replace with libayatana-indicator (requires little or no porting?); orphaned
Little porting, for renderers only. SNI applications don't directly depend on lib(ayatana)-indicator. 


src:libappindicator (libappindicator(3-)?1):
deprecated library for SNI client apps; replace with libayatana-appindicator
(requires little or no porting?); orphaned


Little porting. Here is an example for transmission-gtk:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894410

It basically can be reduced to a 2-3 liner patch.
Porting an SNI application from libappindicator to libayatana-appindicator implicitly ports it from libindicator to libayatana-indicator. 


src:libindicate (libindicate5, libindicate-gtk*):
deprecated^2 library for SNI client apps; replace with
libayatana-appindicator (requires non-trivial porting); orphaned, should
be removed
Nope. The libindicate library can be dropped completely. Implementations can simply be removed from applications, the libindicate code path was used to notify (ayatana-)indicator-messages about new events having occurred in communication applications (new email, new chat post, etc.). 

I will look deeper into this after Easter.


... and many of those have both GTK+ 2 and GTK+ 3 flavours, and sometimes
a separate GUI-agnostic shared library for D-Bus protocols.


Yes.


I hope you can see why I was confused by all the
lib(ayatana-)?(app)?indicat(e|or)((-gtk)?3)? libraries involved in this!



Absolutely!!!


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?
Some little source code porting is needed. My goal was to allow parallel installation of lib(app)indicator and libayatana-(app)indicator. 

Here are some examples:

Simple patch, exchange libappindicator by libayatana-appindicator:
transmission-gtk: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=894410;filename=transmission_2.92-3_2.92-3%2Bayatanaindicators.debdiff;msg=5
More complex patch: support building against libappindicator and libayatana-appindicator alike (available shared libs decides what to build against): nm-applet: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=880169;filename=network-manager-applet_1.8.4-1%2Bayatanaindicator.debdiff;msg=10 
mate-polkit: https://github.com/mate-desktop/mate-polkit/pull/41
Even more complex; choose what indicator implementation to use by configure option (a renderer, though): 
https://github.com/mate-desktop/mate-indicator-applet/commit/9d6ee461f95e059a42aea9392c37f5a752e9be3d


(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.)


Yes. That's true. The renderers are countable with fingers of both hands.


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?


Yes, the future is SNI.
The nice part of AppIndicator shared lib: if no SNI provider is running on a desktop, xembed gets used. (Very helpful on my favourite desktop shell i3). So, as application developer, you can drop your own xembed code, switch to Ayatana AppIndicator and get the xembed fallback for free.
Only disadvantage: application indicators don't have a right-click menu, only a left-click or just-click menu. Also in xembed fallback mode. 


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.
Ah, ok. I see. This is painful, but alas. The xembed approach is really on its verge of extinction. However, when Ubuntu dropped xembed support in 12.10, I think it was, there was quite some noise going through the community. 

Thanks for leading this discussion,

Mike
PS: I will be nearly 100% afk over Easter, but don't hesitate to ask more questions / provide ideas for the transition management. I'll get back to your emails on Tuesday. 

--

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: pgpoP8m_yuvt3.pgp
Description: Digitale PGP-Signatur

Reply to: