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

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



Hi Ian,

On  Di 03 Apr 2018 20:20:15 CEST, Ian Jackson wrote:

Chris Lamb writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
Hi Mike et al.,
> This is to make people aware and inform about an ongoing effort to
> replace Indicators in Debian

Just in case it helps others unfamiliar with the entire concept of
Indicators (I was until now!) here is some background info:

https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Summary

That's very informative.

It's also rather worrying.  It does not seem to provide an answer for
users who like and have grown used to the existing arrangements, and
the behaviour of their existing panel widgets.

The motive for this change seems to have been to increase the
behavioural uniformity of things in panels, but given that the plan
involves changing every applet to use a new library, that could have
been done without a change of protocol.

I guess the MATE panel will continue to offer xembed support ?

The overall difference between both approaches is about who does the rendering of the systray icon and its menu.

The xembed protocol is described here [1]. It is fully based on X11 windows and reparenting and does not at all care about content, menu structures, widgets. The specification is really really old.

The AppIndicator approach is content gnostic. The applet hands over the menu tree to the renderer and the renderer does the rendering. UI integration, theming integration and a11y integration is fully controlled by the renderer (on a GTK3 desktop, this is some sort of GTK3 toolkit stuff that does the rendering, whereas on a Qt5 based desktop, this is done by some Qt5 toolkit stuff).

With xembed, the user is pretty much left alone, esp. regarding a11y integration (esp. keyboard control of the systray area).

In Ayatana Indicators, we will provide a system indicator that will become container for xembed based applications. Furthermore, MATE's notification area applet (that hosts xembedded apps currently) is not planned to be removed any time soon (AFAIK).

And as I said earlier, lib(ayatana-)appindicator falls back to xembed, if no SNI provider is around on the user session DBus.

However, when people start writing a new application and want to dock it to the panel... They should not use xembed anymore.

And: I am fully aware of the xembed-removal history in GNOME/Unity7 [2]. That was not fun at all 5 years ago. We won't copy that over-assumptuous flaw again. Legacy support is important, so xembed support needs to stay, while people should be encourage to go the AppIndicator way for new and actively maintained applications.

Hope that soothes things a bit,
Mike

[1] https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunweaver@debian.org, http://sunweavers.net

Attachment: pgpGqLHaHJYRR.pgp
Description: Digitale PGP-Signatur


Reply to: