Re: Upcoming shift to Ayatana (App)Indicator(s)
- Date: Wed, 04 Apr 2018 13:18:46 +0000
- From: Mike Gabriel <sunweaver@xxxxxxxxxx>
- Subject: 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#SummaryThat'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 . 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 . 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  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@xxxxxxxxxx, http://sunweavers.net
Description: Digitale PGP-Signatur
- Prev by Date: Re: Reiser4 Kernel 4.15.15 and Upgraded wireless-regdb for Debian AMD64
- Next by Date: Bug#894814: ITP: multimon-ng -- digital radio transmission decoder
- Previous by thread: Re: Upcoming shift to Ayatana (App)Indicator(s)
- Next by thread: Re: Upcoming shift to Ayatana (App)Indicator(s)