Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Upcoming shift to Ayatana (App)Indicator(s)
223 views
Skip to first unread message
Mike Gabriel
Mar 29, 2018, 9:20:02 AM3/29/18
to
Hi all,
I send out my recent blog post to the debian-devel ML to provide a
means for bundled feedback. I am also hoping for feedback from Ubuntu
developers. On DebConf17 I talked to Dmitry John Ledkov about the idea
of having Indicators maintained outside of Ubuntu and the idea found
interest. (Although the renaming in the shared lib has caused some
pain to people, but so be it now).
This mail is also intended for members of the release team, as I need
advice on how to address such a transition (or rather "shift") in
Debian's BTS. As this is not a real shared lib bin:pkg transition, I
feel.
Thanks for your contributions already!
Mike
PS: please Cc: me when replying, so I don't miss your thoughts...
----------------------
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.
## TL;DR;
In Debian, we will soon start sending out patches too SNI supporting
applications via Debian's BTS (and upstream trackers, too, probably),
that make the shift from Ubuntu AppIndicator (badly maintained in
Debian) to Ayatana AppIndicator.
Status of the work being done is documented here:
https://wiki.debian.org/Ayatana/IndicatorsTransition
## Why Ayatana Indicators
The fork is currently pushed forward by the Debian and Ubuntu MATE
packaging team.
The Indicators concept has originally been documented by Canonical,
find your entry point in the readings here [1,2].
Some great work and achievement was done around Ubuntu Indicators by
Canonical Ltd. and the Indicators concept has always been a special
identifying feature of Ubuntu. Now with the switch to GNOMEv3, the
future of Indicators in Ubuntu is uncertain. This is where Ayatana
Indicators come in...
The main problem with Ubuntu Indicators today (and ever since) is (has
been): they only work properly on Ubuntu, mostly because of one
Ubuntu-specific patch against GTK-3 [3].
In Ayatana Indicators (speaking with my upstream hat on now), we are
currently working on a re-implementation of the rendering part of the
indicators (using GTK's popovers rather then menushells), so that it
works on vanilla GTK-3. Help from GTK-3 developers is highly welcome,
in case you feel like chiming in.
Furthermore, the various indicator icons in Ubuntu (-session, -power,
-sound, etc. - see below for more info) have been targetted more and
more for sole usage with the Unity 7 and 8 desktop environments. They
can be used with other desktop environments, but are likely to behave
quite agnostic (and sometimes stupid) there.
In Ayatana Indicators, we are working on generalizing the
functionality of those indicator icon applications and make them more
gnostic on other desktop environments.
Ayatana Indicators as an upstream project will be very open to
contributions from other desktop environment developers that want to
utilize the indicator icons with their desktop shell, but need
adaptations for their environment. Furthermore, we want to encourage
Unity 7 and Unity 8 developers to consider switching over (and getting
one step further with the goal of shipping Unity on non-Ubuntu
systems). With the Unity 8 maintainers (the people from UBports /
Ubuntu Touch) first discussion exchanges have taken place.
## The different Components of Ayatana Indicators
### The 'indicator-renderer' Applets
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).
Letting the desktop environment render the system tray itself assures
that the indicator icons (i.e. the desktop system tray) looks just
like the rest of the desktop shell. With the classical (xembed based)
system tray (or notification) areas, all applications render their
icon and menus themselves, which can cause theming problems and a11y
issues and more.
Examples of indicator renderers are: ``mate-indicator-applet``,
``budgie-indicator-applet``, ``xfce4-indicator-pluign``, etc.
### Shared Library: Rendering and Loading of Indicators
The Ayatana Indicators project currently only provides a rendering
shared lib for GTK-2 and GTK-3 based applications. We still need to
connect better with the Qt-world.
The rendering library (used by the above renderers) is libayatana-indicator.
This library supports:
* loading and rendering of old style indicators
* loading and rendering of NG indicators
The libayatana-indicator library also utilizes a variety of versatile
GTK-3 widget defined in another shared library: aytana-ido.
### Ayatana Indicator Applets
The Ayatana Indicators project continues and generalizes various
indicator icon applications that are not applications by themselves
really, but more like system / desktop control elements:
* ayatana-indicator-session (logout, lock screen, user guides, etc.)
* ayatana-indicator-power (power management)
* ayatana-indicator-sound (sound and multimedia control)
* ayatana-indicator-datetime (clock, calendar,
evolution-data-server integration)
* ayatana-indicator-notifications (libnotify collector of system messages)
* ayatana-indicator-printers (interact with CUPS print jobs and queues)
These indicators are currently under heavy re-development. The current
effort in Ayatana Indicators is to make them far more generic and
usable on all desktop environments that want to support them. E.g. we
recently added XFCE awareness to the -session and the -power indicator
icons.
One special indicator icon is the Ayatana Indicator Application
indicator. It provides SNI support to third-party applications (see
below). For the desktop applet, it appears just like any of the other
above named indicators, but it opens the door to the world of SNI
supporting applications.
One available and easy-to-install test case in Debian buster for
indicator icons provided by the Ayatana Indicators project is the
arctica-greeter package. The icons displayed in the greeter are
Ayatana Indicators.
### Ayatana AppIndicator API
The Ayatana AppIndicator API is just one way of talking to an SNI DBus
service. The implementation is done in the shared lib
'libayatana-appindicator'. This library provides an easy to implement
API that allows GTK-2/3 applications to create an indicator icon in a
panel with an indicator renderer added.
In the application, the developer creates a generic menu structure and
defines one or more icons for the system tray (more than one icon:
only one icon is shown (plus some text, if needed), but that icon may
changed based on the applet's status). This generic menu is sent to a
DBus interface (org.kde.StatusNotifier). Sometimes, people say, that
such applications have SNI support (StatusNotifier Interface support).
The Ayatana Indicators project offers Ayatana AppIndicator to GTK-3
developers (and GTK-2, but well...). Canonical implemented bindings
for Python2, Perl, GIR, Mono/CLI and we continue to support these as
long as it makes sense.
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.
In Debian, we will start sending out patches too SNI supporting
applications soon, that make the shift from Ubuntu AppIndicator (badly
maintained in Debian) to Ayatana AppIndicator. The cool part of this
is, you can convert your GTK-3 application from Ubuntu AppIndicator to
Ayatana AppIndicator and use it on top of any(!) SNI implementation,
be it an applet based on Ubuntu Indicators, based on Ayatana
Indicators or some other implementation, like the vala-sntray-applet
or SNI support in KDE.
## Further Readings
Some more URLs for deeper reading...
* For the new upstream project, we have started a minimal web page:
https://ayatanaindicators.github.io/
* Upstream development takes place on Github:
https://github.com/AyatanaIndicators
* The always up-to-date status of Ayatana Indicators in Debian is
documented here: https://wiki.debian.org/Ayatana/IndicatorsTransition
* See also our DDPO overview page:
https://qa.debian.org/developer.php?login=pkg-ayatana-devel%40lists.alioth.debian.org
You can also find more info on my blog: https://sunweavers.net
## References
* [1] https://wiki.ubuntu.com/Indicators
* [2] https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
* [3]
https://bazaar.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3/view/head:/debian/patches/ubuntu_gtk_custom_menu_items.patch
--
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: sunw...@debian.org, http://sunweavers.net
I send out my recent blog post to the debian-devel ML to provide a
means for bundled feedback. I am also hoping for feedback from Ubuntu
developers. On DebConf17 I talked to Dmitry John Ledkov about the idea
of having Indicators maintained outside of Ubuntu and the idea found
interest. (Although the renaming in the shared lib has caused some
pain to people, but so be it now).
This mail is also intended for members of the release team, as I need
advice on how to address such a transition (or rather "shift") in
Debian's BTS. As this is not a real shared lib bin:pkg transition, I
feel.
Thanks for your contributions already!
Mike
PS: please Cc: me when replying, so I don't miss your thoughts...
----------------------
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.
## TL;DR;
In Debian, we will soon start sending out patches too SNI supporting
applications via Debian's BTS (and upstream trackers, too, probably),
that make the shift from Ubuntu AppIndicator (badly maintained in
Debian) to Ayatana AppIndicator.
Status of the work being done is documented here:
https://wiki.debian.org/Ayatana/IndicatorsTransition
## Why Ayatana Indicators
The fork is currently pushed forward by the Debian and Ubuntu MATE
packaging team.
The Indicators concept has originally been documented by Canonical,
find your entry point in the readings here [1,2].
Some great work and achievement was done around Ubuntu Indicators by
Canonical Ltd. and the Indicators concept has always been a special
identifying feature of Ubuntu. Now with the switch to GNOMEv3, the
future of Indicators in Ubuntu is uncertain. This is where Ayatana
Indicators come in...
The main problem with Ubuntu Indicators today (and ever since) is (has
been): they only work properly on Ubuntu, mostly because of one
Ubuntu-specific patch against GTK-3 [3].
In Ayatana Indicators (speaking with my upstream hat on now), we are
currently working on a re-implementation of the rendering part of the
indicators (using GTK's popovers rather then menushells), so that it
works on vanilla GTK-3. Help from GTK-3 developers is highly welcome,
in case you feel like chiming in.
Furthermore, the various indicator icons in Ubuntu (-session, -power,
-sound, etc. - see below for more info) have been targetted more and
more for sole usage with the Unity 7 and 8 desktop environments. They
can be used with other desktop environments, but are likely to behave
quite agnostic (and sometimes stupid) there.
In Ayatana Indicators, we are working on generalizing the
functionality of those indicator icon applications and make them more
gnostic on other desktop environments.
Ayatana Indicators as an upstream project will be very open to
contributions from other desktop environment developers that want to
utilize the indicator icons with their desktop shell, but need
adaptations for their environment. Furthermore, we want to encourage
Unity 7 and Unity 8 developers to consider switching over (and getting
one step further with the goal of shipping Unity on non-Ubuntu
systems). With the Unity 8 maintainers (the people from UBports /
Ubuntu Touch) first discussion exchanges have taken place.
## The different Components of Ayatana Indicators
### The 'indicator-renderer' Applets
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).
Letting the desktop environment render the system tray itself assures
that the indicator icons (i.e. the desktop system tray) looks just
like the rest of the desktop shell. With the classical (xembed based)
system tray (or notification) areas, all applications render their
icon and menus themselves, which can cause theming problems and a11y
issues and more.
Examples of indicator renderers are: ``mate-indicator-applet``,
``budgie-indicator-applet``, ``xfce4-indicator-pluign``, etc.
### Shared Library: Rendering and Loading of Indicators
The Ayatana Indicators project currently only provides a rendering
shared lib for GTK-2 and GTK-3 based applications. We still need to
connect better with the Qt-world.
The rendering library (used by the above renderers) is libayatana-indicator.
This library supports:
* loading and rendering of old style indicators
* loading and rendering of NG indicators
The libayatana-indicator library also utilizes a variety of versatile
GTK-3 widget defined in another shared library: aytana-ido.
### Ayatana Indicator Applets
The Ayatana Indicators project continues and generalizes various
indicator icon applications that are not applications by themselves
really, but more like system / desktop control elements:
* ayatana-indicator-session (logout, lock screen, user guides, etc.)
* ayatana-indicator-power (power management)
* ayatana-indicator-sound (sound and multimedia control)
* ayatana-indicator-datetime (clock, calendar,
evolution-data-server integration)
* ayatana-indicator-notifications (libnotify collector of system messages)
* ayatana-indicator-printers (interact with CUPS print jobs and queues)
These indicators are currently under heavy re-development. The current
effort in Ayatana Indicators is to make them far more generic and
usable on all desktop environments that want to support them. E.g. we
recently added XFCE awareness to the -session and the -power indicator
icons.
One special indicator icon is the Ayatana Indicator Application
indicator. It provides SNI support to third-party applications (see
below). For the desktop applet, it appears just like any of the other
above named indicators, but it opens the door to the world of SNI
supporting applications.
One available and easy-to-install test case in Debian buster for
indicator icons provided by the Ayatana Indicators project is the
arctica-greeter package. The icons displayed in the greeter are
Ayatana Indicators.
### Ayatana AppIndicator API
The Ayatana AppIndicator API is just one way of talking to an SNI DBus
service. The implementation is done in the shared lib
'libayatana-appindicator'. This library provides an easy to implement
API that allows GTK-2/3 applications to create an indicator icon in a
panel with an indicator renderer added.
In the application, the developer creates a generic menu structure and
defines one or more icons for the system tray (more than one icon:
only one icon is shown (plus some text, if needed), but that icon may
changed based on the applet's status). This generic menu is sent to a
DBus interface (org.kde.StatusNotifier). Sometimes, people say, that
such applications have SNI support (StatusNotifier Interface support).
The Ayatana Indicators project offers Ayatana AppIndicator to GTK-3
developers (and GTK-2, but well...). Canonical implemented bindings
for Python2, Perl, GIR, Mono/CLI and we continue to support these as
long as it makes sense.
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.
In Debian, we will start sending out patches too SNI supporting
applications soon, that make the shift from Ubuntu AppIndicator (badly
maintained in Debian) to Ayatana AppIndicator. The cool part of this
is, you can convert your GTK-3 application from Ubuntu AppIndicator to
Ayatana AppIndicator and use it on top of any(!) SNI implementation,
be it an applet based on Ubuntu Indicators, based on Ayatana
Indicators or some other implementation, like the vala-sntray-applet
or SNI support in KDE.
## Further Readings
Some more URLs for deeper reading...
* For the new upstream project, we have started a minimal web page:
https://ayatanaindicators.github.io/
* Upstream development takes place on Github:
https://github.com/AyatanaIndicators
* The always up-to-date status of Ayatana Indicators in Debian is
documented here: https://wiki.debian.org/Ayatana/IndicatorsTransition
* See also our DDPO overview page:
https://qa.debian.org/developer.php?login=pkg-ayatana-devel%40lists.alioth.debian.org
You can also find more info on my blog: https://sunweavers.net
## References
* [1] https://wiki.ubuntu.com/Indicators
* [2] https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
* [3]
https://bazaar.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3/view/head:/debian/patches/ubuntu_gtk_custom_menu_items.patch
--
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: sunw...@debian.org, http://sunweavers.net
Simon McVittie
Mar 29, 2018, 10:00:03 AM3/29/18
to
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
> 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.
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.
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)
* deprecated but still supported (preferably documented by an upload
and/or ftp.debian.org bug overriding their Section to oldlibs)
* 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)
> 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).
https://github.com/Ubuntu/gnome-shell-extension-appindicator is the
recommended implementation of this for GNOME 3?
> 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.
XEmbed-based tray icons, which are increasingly poorly supported and have
no Wayland implementation?
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).
smcv
Chris Lamb
Mar 29, 2018, 1:00:03 PM3/29/18
to
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
Mike also did a talk at DebConf:
https://debconf17.debconf.org/talks/168/
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
> This is to make people aware and inform about an ongoing effort to
> replace Indicators in Debian
Indicators (I was until now!) here is some background info:
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Summary
Mike also did a talk at DebConf:
https://debconf17.debconf.org/talks/168/
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Mike Gabriel
Mar 29, 2018, 5:30:03 PM3/29/18
to
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
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.
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)
> * deprecated but still supported (preferably documented by an upload
> and/or ftp.debian.org bug overriding their Section to oldlibs)
> * 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)
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?
(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?
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).
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.g...@das-netzwerkteam.de, http://das-netzwerkteam.de
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
Simon McVittie
Mar 29, 2018, 7:30:02 PM3/29/18
to
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
> 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:
libraries to which an indicator client might be linked, from a Debian
perspective?
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)
src:libayatana-appindicator (libayatana-appindicator(3-)?1):
maintained fork of libappindicator, recommended for SNI client apps
src:libdbusmenu:
dependency of lib(ayatana-)?appindicator and libindicate
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
src:libappindicator (libappindicator(3-)?1):
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
be removed
... 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.
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.
on GNOME Shell not dropping XEmbed support completely. I don't have the
necessary knowledge or bandwidth to become its upstream maintainer.
smcv
Mike Gabriel
Mar 30, 2018, 2:10:02 PM3/30/18
to
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.
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?
> 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)
"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
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
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
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
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
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.
> 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?
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.)
>>> 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?
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.
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.
Ian Jackson
Apr 3, 2018, 2:20:02 PM4/3/18
to
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
using/maintaining may break.
I currently use `trayer' to contain a few small widgety things for
network-manager etc. This works well.
I also have an (symbiosisware, so as yet unreleased) program which
uses tk-tktray (package `tktray'), and embeds an X window belonging to
a different executable.
I have two questions:
1. Is there some risk that trayer will stop being able to
handle applets from things like network-manager ?
If so what should I replace it with ?
2. Is there some risk that tktray will not work with the
answer to (1) ? If so what should I replace it with ?
Answers to 1 should not suppose that I want to change my window
manager or adopt a full-on `desktop environment' or a `panel' (unless
perhaps the panel can be made to be as small as its contents). My
window manager is vtwm.
Answers to 2 should ideally suppose that I want to continue to use
XID-based window embedding to make an applet which contains the window
from a separate X client.
I note that neither trayer nor tktray seem to involve any of the
libraries being discussed in this thread. Is that because an
`indicator' is not the same as an `applet', or is it due to churn, or
something else ?
Thanks,
Ian.
> On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
> > 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 haven't been keeping up with this but I suspect that something I am
> > 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.).
using/maintaining may break.
I currently use `trayer' to contain a few small widgety things for
network-manager etc. This works well.
I also have an (symbiosisware, so as yet unreleased) program which
uses tk-tktray (package `tktray'), and embeds an X window belonging to
a different executable.
I have two questions:
1. Is there some risk that trayer will stop being able to
handle applets from things like network-manager ?
If so what should I replace it with ?
2. Is there some risk that tktray will not work with the
answer to (1) ? If so what should I replace it with ?
Answers to 1 should not suppose that I want to change my window
manager or adopt a full-on `desktop environment' or a `panel' (unless
perhaps the panel can be made to be as small as its contents). My
window manager is vtwm.
Answers to 2 should ideally suppose that I want to continue to use
XID-based window embedding to make an applet which contains the window
from a separate X client.
I note that neither trayer nor tktray seem to involve any of the
libraries being discussed in this thread. Is that because an
`indicator' is not the same as an `applet', or is it due to churn, or
something else ?
Thanks,
Ian.
Ian Jackson
Apr 3, 2018, 2:20:02 PM4/3/18
to
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
> 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.
This seems encouraging for people like me who want to continue to use
> 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.
trayer.
> Only disadvantage: application indicators don't have a right-click
> menu, only a left-click or just-click menu. Also in xembed fallback
> mode.
My n-m applet in trayer does have a right click menu.
> 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.
original protocol is wrong and why the replacement will not, itself,
need to be replaced ?
Ian.
--
Ian Jackson <ijac...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Ian Jackson
Apr 3, 2018, 2:30:02 PM4/3/18
to
Chris Lamb writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
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 ?
> 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.
> > 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
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 ?
Mike Gabriel
Apr 4, 2018, 9:20:03 AM4/4/18
to
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
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 ?
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
Apr 4, 2018, 9:30:02 AM4/4/18
to
Hi Ian,
On Di 03 Apr 2018 20:15:31 CEST, Ian Jackson wrote:
> Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
>> 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.
>
> This seems encouraging for people like me who want to continue to use
> trayer.
Hmmm... The trayer package depends on GTK-2. I think that this will be
your real problem in 2-3 years from now.
And... With some GTK knowledge, it could probably easily be ported to
GTK3 and AppIndicator + Xembed support.
So, regarding the still-GTK-2 problem, some work needs to be done
upstream'ish or it will vanish from Debian, possibly in buster+1.
>> Only disadvantage: application indicators don't have a right-click
>> menu, only a left-click or just-click menu. Also in xembed fallback
>> mode.
>
> Is this a general property of SNI indicators ?
> My n-m applet in trayer does have a right click menu.
The nm-applet in Debian has AppIndicator support disabled. If you
build it with AppIndicator (see my patch in [1]) and you enable the
AppIndicator code path with "nm-applet --indicator", you will see that
the left-click and right-click menus have been merged.
>> 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.
>
> Is there somewhere I can see a rationale which explains why the
> original protocol is wrong and why the replacement will not, itself,
> need to be replaced ?
The rationale is mainly about who does the X11 rendering [2].
Furthermore, Xembed is X11. In Wayland, I have heard, there is no
Wembed.
Mike
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880169
[2] http://agateau.com/2011/statusnotifieritem-for-qt-applications/
On Di 03 Apr 2018 20:15:31 CEST, Ian Jackson wrote:
> Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
>> 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.
>
> This seems encouraging for people like me who want to continue to use
> trayer.
your real problem in 2-3 years from now.
And... With some GTK knowledge, it could probably easily be ported to
GTK3 and AppIndicator + Xembed support.
So, regarding the still-GTK-2 problem, some work needs to be done
upstream'ish or it will vanish from Debian, possibly in buster+1.
>> Only disadvantage: application indicators don't have a right-click
>> menu, only a left-click or just-click menu. Also in xembed fallback
>> mode.
>
> Is this a general property of SNI indicators ?
> My n-m applet in trayer does have a right click menu.
build it with AppIndicator (see my patch in [1]) and you enable the
AppIndicator code path with "nm-applet --indicator", you will see that
the left-click and right-click menus have been merged.
>> 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.
>
> Is there somewhere I can see a rationale which explains why the
> original protocol is wrong and why the replacement will not, itself,
> need to be replaced ?
Furthermore, Xembed is X11. In Wayland, I have heard, there is no
Wembed.
Mike
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880169
[2] http://agateau.com/2011/statusnotifieritem-for-qt-applications/
Mike Gabriel
Apr 4, 2018, 9:50:03 AM4/4/18
to
Hi Ian,
On Di 03 Apr 2018 20:11:43 CEST, Ian Jackson wrote:
> Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
>> On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
>> > 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.).
>
> [...]
The fancy widgets (sliders, etc.) for now appear in _system_
indicators, only. They are special indicators in MATE, XFCE
(optionally), possibly Budgie (optionally), that have a special
rendering and don't use the StatusNotifierItem implementation. (And
they don't work, yet, on Debian, only on Ubuntu, because they require
some Ubuntu'ish GTK-3 patch).
The AppIndicator based applications only use menu items (widgets) that
have been used in Xembed based systray menus, so far.
> I also have an (symbiosisware, so as yet unreleased) program which
> uses tk-tktray (package `tktray'), and embeds an X window belonging to
> a different executable.
to work, as long as a desktop env provides Xembed support. However, I
wouldn't code new projects based on tk-tkray.
> Answers to 1 should not suppose that I want to change my window
> manager or adopt a full-on `desktop environment' or a `panel' (unless
The window manager is +/- totally unrelated to the topic.
> perhaps the panel can be made to be as small as its contents). My
> window manager is vtwm.
Some weeks ago, I uploaded the vala-panel package to unstable. It
supports AppIndicators and Xembed based applications alike. It could
well need some more testers and feedback. However, it is a promising
project esp. for people that don't want to use a specific desktop env
but rather assemble their own working environment.
> Answers to 2 should ideally suppose that I want to continue to use
> XID-based window embedding to make an applet which contains the window
> from a separate X client.
I am not sure, I am fully getting the application design, you have in
mind here. Do you mean X-embedding (this is about icons and systray
and the icons have menus and submenus) or reparenting? With X11
reparenting you can reparent X11 application 1 into X11 application 2.
(xterm has it even as cmdline option).
> I note that neither trayer nor tktray seem to involve any of the
> libraries being discussed in this thread. Is that because an
> `indicator' is not the same as an `applet', or is it due to churn, or
> something else ?
It is because AppIndicator does not do X-embedding at all. And for
X-embedding, you merely new some libX11 calls. AppIndicator / SNI is
about an application (written in GTK, Qt, what-not) sending its menu
tree and systray icon over DBus and on the other end a desktop env
applet (renderer) that pumps this menu structure into the panel (your
elsewhere appropriate).
I you have more question, please ask. Thanks for the discussion!
Mike
On Di 03 Apr 2018 20:11:43 CEST, Ian Jackson wrote:
> Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
>> On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
>> > 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 have two questions:
>
> 1. Is there some risk that trayer will stop being able to
> handle applets from things like network-manager ?
> If so what should I replace it with ?
Not in the foreseeable future, I guess (except from trayer being GTK-2).
> I have two questions:
>
> 1. Is there some risk that trayer will stop being able to
> handle applets from things like network-manager ?
> If so what should I replace it with ?
The fancy widgets (sliders, etc.) for now appear in _system_
indicators, only. They are special indicators in MATE, XFCE
(optionally), possibly Budgie (optionally), that have a special
rendering and don't use the StatusNotifierItem implementation. (And
they don't work, yet, on Debian, only on Ubuntu, because they require
some Ubuntu'ish GTK-3 patch).
The AppIndicator based applications only use menu items (widgets) that
have been used in Xembed based systray menus, so far.
> I also have an (symbiosisware, so as yet unreleased) program which
> uses tk-tktray (package `tktray'), and embeds an X window belonging to
> a different executable.
> 2. Is there some risk that tktray will not work with the
> answer to (1) ? If so what should I replace it with ?
tk-tktray is an API for Xembed'ding a systray icon. This will continue
> answer to (1) ? If so what should I replace it with ?
to work, as long as a desktop env provides Xembed support. However, I
wouldn't code new projects based on tk-tkray.
> Answers to 1 should not suppose that I want to change my window
> manager or adopt a full-on `desktop environment' or a `panel' (unless
> perhaps the panel can be made to be as small as its contents). My
> window manager is vtwm.
supports AppIndicators and Xembed based applications alike. It could
well need some more testers and feedback. However, it is a promising
project esp. for people that don't want to use a specific desktop env
but rather assemble their own working environment.
> Answers to 2 should ideally suppose that I want to continue to use
> XID-based window embedding to make an applet which contains the window
> from a separate X client.
mind here. Do you mean X-embedding (this is about icons and systray
and the icons have menus and submenus) or reparenting? With X11
reparenting you can reparent X11 application 1 into X11 application 2.
(xterm has it even as cmdline option).
> I note that neither trayer nor tktray seem to involve any of the
> libraries being discussed in this thread. Is that because an
> `indicator' is not the same as an `applet', or is it due to churn, or
> something else ?
X-embedding, you merely new some libX11 calls. AppIndicator / SNI is
about an application (written in GTK, Qt, what-not) sending its menu
tree and systray icon over DBus and on the other end a desktop env
applet (renderer) that pumps this menu structure into the panel (your
elsewhere appropriate).
I you have more question, please ask. Thanks for the discussion!
Mike
Ian Jackson
Apr 4, 2018, 10:00:02 AM4/4/18
to
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
> On Di 03 Apr 2018 20:15:31 CEST, Ian Jackson wrote:
> > This seems encouraging for people like me who want to continue to use
> > trayer.
>
> Hmmm... The trayer package depends on GTK-2. I think that this will be
> your real problem in 2-3 years from now.
>
> And... With some GTK knowledge, it could probably easily be ported to
> GTK3 and AppIndicator + Xembed support.
OK, I guess we can cross that bridge when we come to it. It doesn't
> On Di 03 Apr 2018 20:15:31 CEST, Ian Jackson wrote:
> > This seems encouraging for people like me who want to continue to use
> > trayer.
>
> Hmmm... The trayer package depends on GTK-2. I think that this will be
> your real problem in 2-3 years from now.
>
> And... With some GTK knowledge, it could probably easily be ported to
> GTK3 and AppIndicator + Xembed support.
sound too awful.
> > Is this a general property of SNI indicators ?
> > My n-m applet in trayer does have a right click menu.
>
> The nm-applet in Debian has AppIndicator support disabled. If you
> build it with AppIndicator (see my patch in [1]) and you enable the
> AppIndicator code path with "nm-applet --indicator", you will see that
> the left-click and right-click menus have been merged.
to use the xembed approach indefinitely ?
> > Is there somewhere I can see a rationale which explains why the
> > original protocol is wrong and why the replacement will not, itself,
> > need to be replaced ?
>
> The rationale is mainly about who does the X11 rendering [2].
unclear. I meant, what is the reason. "In SNI the panel does the
rendering" is part of the design but does not explain why that
design choice was made.
The page you refer to says simply:
| This led to a lot of inconsistency as each application were
| responsible for the rendering and the behavior of their tiny
| windows.
I discussed this when I wrote this:
> > 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.
change in protocol.
> Furthermore, Xembed is X11. In Wayland, I have heard, there is no
> Wembed.
or contain another. This is far from am unusual requirement. (The
details of the Xembed tray protocol would have to have been redone, I
suppose.)
It seems to me that the new proto is strictly worse than the old one.
It has fewer capabilities. In particular, it is not possible, with
the new protocol, to make applets which deviate from the uniform SNI
UI. It is unarguable that such deviation is sometimes desirable,
since no doubt there are users who prefer it.
ISTM therefore that the old protocol needs to be retained
indefinitely. That might mean that in Wayland some applets (that want
a richer UI) run in Wayland's X11 emulation, but I don't see a problem
with that. Nor do I see a problem with retaining that indefinitely.
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
> The overall difference between both approaches is about who does the
> rendering of the systray icon and its menu.
Thanks for the explanation. I had understood this from reading the
> rendering of the systray icon and its menu.
earlier links.
> 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).
> 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.
I think that application authors should be encouraged to use whatever
interface seems most convenient for them. If the applet-facing APIs
provided for SNI meet their needs, and are convenient, then the applet
author can choose SNI.
If on the other hand, the SNI APIs are not convenient, or the applet
author wants a richer UI than supported by SNI, then the xembed
approach may be better.
An applet written in Tcl/Tk is a good example of a case where xembed
is probably better, since Tcl's tk-tktray package provides an
interface which is simultaneously extremely convenient for the
programmer, and powerful and flexible. It is hard to see how the
dbus-based SNI approach would fit nicely into Tcl/Tk.
> Hope that soothes things a bit,
I still don't quite agree with all the design decisions here, as you
will see, but it's not my design or my code. If I can continue to use
xembed indefinitely then I'm content.
Regards,
Mike Gabriel
Apr 4, 2018, 10:10:02 AM4/4/18
to
Hi Ian,
now I see clearer...
On Mi 04 Apr 2018 16:00:41 CEST, Ian Jackson wrote:
> Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
>> On Di 03 Apr 2018 20:11:43 CEST, Ian Jackson wrote:
>> > Answers to 2 should ideally suppose that I want to continue to use
>> > XID-based window embedding to make an applet which contains the window
>> > from a separate X client.
>>
>> I am not sure, I am fully getting the application design, you have in
>> mind here. Do you mean X-embedding (this is about icons and systray
>> and the icons have menus and submenus) or reparenting? With X11
>> reparenting you can reparent X11 application 1 into X11 application 2.
>> (xterm has it even as cmdline option).
>
> My applet has *both* of the above. Firstly, the applet uses the
> xembed protocol (via the tcl tktray package) to embed its toplevel X11
> window into the tray (provided by trayer, although I don't see why it
> shouldn't work with a full-on DE).
This is old-style systray icon creation. Still supported on all DEs
with Xembed support in this or that way.
> Secondly, the applet's tcl code makes a subwindow (using `frame
> -container'), whose X11 window ID it passes to a separate program;
> that separate program is given the window ID with -into and makes its
> own window a child of the applet's.
Not related to the systray topic at all, however this is an X11-only
technique (I am no Wayland nor Mir expert, so others may please
correct me). On non-X11 graphical backend engines, you will need some
X11 layer in the middle (between your application and the underlying
Compositor).
> So, overall, the subprocess's rendering is displayed in the tray; but
> the tcl code handles user mouse input etc.
Yep. Now understood.
> Regards,
> Ian.
now I see clearer...
On Mi 04 Apr 2018 16:00:41 CEST, Ian Jackson wrote:
> Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
>> On Di 03 Apr 2018 20:11:43 CEST, Ian Jackson wrote:
>> > Answers to 2 should ideally suppose that I want to continue to use
>> > XID-based window embedding to make an applet which contains the window
>> > from a separate X client.
>>
>> I am not sure, I am fully getting the application design, you have in
>> mind here. Do you mean X-embedding (this is about icons and systray
>> and the icons have menus and submenus) or reparenting? With X11
>> reparenting you can reparent X11 application 1 into X11 application 2.
>> (xterm has it even as cmdline option).
>
> xembed protocol (via the tcl tktray package) to embed its toplevel X11
> window into the tray (provided by trayer, although I don't see why it
> shouldn't work with a full-on DE).
This is old-style systray icon creation. Still supported on all DEs
with Xembed support in this or that way.
> Secondly, the applet's tcl code makes a subwindow (using `frame
> -container'), whose X11 window ID it passes to a separate program;
> that separate program is given the window ID with -into and makes its
> own window a child of the applet's.
Not related to the systray topic at all, however this is an X11-only
technique (I am no Wayland nor Mir expert, so others may please
correct me). On non-X11 graphical backend engines, you will need some
X11 layer in the middle (between your application and the underlying
Compositor).
> So, overall, the subprocess's rendering is displayed in the tray; but
> the tcl code handles user mouse input etc.
Yep. Now understood.
> Regards,
> Ian.
Ian Jackson
Apr 4, 2018, 10:10:02 AM4/4/18
to
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
> On Di 03 Apr 2018 20:11:43 CEST, Ian Jackson wrote:
> > Answers to 2 should ideally suppose that I want to continue to use
> > XID-based window embedding to make an applet which contains the window
> > from a separate X client.
>
> I am not sure, I am fully getting the application design, you have in
> mind here. Do you mean X-embedding (this is about icons and systray
> and the icons have menus and submenus) or reparenting? With X11
> reparenting you can reparent X11 application 1 into X11 application 2.
> (xterm has it even as cmdline option).
> On Di 03 Apr 2018 20:11:43 CEST, Ian Jackson wrote:
> > Answers to 2 should ideally suppose that I want to continue to use
> > XID-based window embedding to make an applet which contains the window
> > from a separate X client.
>
> I am not sure, I am fully getting the application design, you have in
> mind here. Do you mean X-embedding (this is about icons and systray
> and the icons have menus and submenus) or reparenting? With X11
> reparenting you can reparent X11 application 1 into X11 application 2.
> (xterm has it even as cmdline option).
My applet has *both* of the above. Firstly, the applet uses the
xembed protocol (via the tcl tktray package) to embed its toplevel X11
window into the tray (provided by trayer, although I don't see why it
shouldn't work with a full-on DE).
xembed protocol (via the tcl tktray package) to embed its toplevel X11
window into the tray (provided by trayer, although I don't see why it
shouldn't work with a full-on DE).
Secondly, the applet's tcl code makes a subwindow (using `frame
-container'), whose X11 window ID it passes to a separate program;
that separate program is given the window ID with -into and makes its
own window a child of the applet's.
-container'), whose X11 window ID it passes to a separate program;
that separate program is given the window ID with -into and makes its
own window a child of the applet's.
So, overall, the subprocess's rendering is displayed in the tray; but
the tcl code handles user mouse input etc.
Regards,
the tcl code handles user mouse input etc.
Ian.
Mike Gabriel
Apr 4, 2018, 10:50:03 AM4/4/18
to
Hi Ian,
On Mi 04 Apr 2018 15:51:35 CEST, Ian Jackson wrote:
>> The rationale is mainly about who does the X11 rendering [2].
>
> Thanks. I read your link. Perhaps my use of the word `rationale' was
> unclear. I meant, what is the reason. "In SNI the panel does the
> rendering" is part of the design but does not explain why that
> design choice was made.
> The page you refer to says simply:
>
> | This led to a lot of inconsistency as each application were
> | responsible for the rendering and the behavior of their tiny
> | windows.
>
> I discussed this when I wrote this:
>
>> > 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.
>
> So as I say the desire for uniformity does not seem to explain the
> change in protocol.
I haven't designed the protocol myself, but started fancying it some
years back.
I guess the overall decision was to detach application / system
indicator from rendering on Ubuntu platform.
E.g. the system indicators (that are special in themselves) run as a
service and pump their stuff to the renderer. In Unity7 this was some
gnome-like applet based on GTK. On Unity8, it was some Qt5/QML
renderer. Furthermore, it was not running on X11 there, but on Mir.
(Or rather: is running there...).
So cross-desktop-GUI-widget-toolkit was one part of the protocol
switch decision, I guess. Uniformity another. Making things X11
independent the next. Just guessing here, but the hints are somehow
evident.
>> Furthermore, Xembed is X11. In Wayland, I have heard, there is no
>> Wembed.
>
> There must surely be a way in Wayland for one application to swallow
> or contain another. This is far from am unusual requirement. (The
> details of the Xembed tray protocol would have to have been redone, I
> suppose.)
Is there? I'd be interested to know.
> I still don't quite agree with all the design decisions here, as you
> will see, but it's not my design or my code. If I can continue to use
> xembed indefinitely then I'm content.
I take this last passage with me from our exchange. Xembed support
counts (and I have been there, too, even before this exchange).
light+love,
Mike
On Mi 04 Apr 2018 15:51:35 CEST, Ian Jackson wrote:
>> The rationale is mainly about who does the X11 rendering [2].
>
> Thanks. I read your link. Perhaps my use of the word `rationale' was
> unclear. I meant, what is the reason. "In SNI the panel does the
> rendering" is part of the design but does not explain why that
> design choice was made.
> The page you refer to says simply:
>
> | This led to a lot of inconsistency as each application were
> | responsible for the rendering and the behavior of their tiny
> | windows.
>
> I discussed this when I wrote this:
>
>> > 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.
>
> So as I say the desire for uniformity does not seem to explain the
> change in protocol.
years back.
I guess the overall decision was to detach application / system
indicator from rendering on Ubuntu platform.
E.g. the system indicators (that are special in themselves) run as a
service and pump their stuff to the renderer. In Unity7 this was some
gnome-like applet based on GTK. On Unity8, it was some Qt5/QML
renderer. Furthermore, it was not running on X11 there, but on Mir.
(Or rather: is running there...).
So cross-desktop-GUI-widget-toolkit was one part of the protocol
switch decision, I guess. Uniformity another. Making things X11
independent the next. Just guessing here, but the hints are somehow
evident.
>> Furthermore, Xembed is X11. In Wayland, I have heard, there is no
>> Wembed.
>
> There must surely be a way in Wayland for one application to swallow
> or contain another. This is far from am unusual requirement. (The
> details of the Xembed tray protocol would have to have been redone, I
> suppose.)
> I still don't quite agree with all the design decisions here, as you
> will see, but it's not my design or my code. If I can continue to use
> xembed indefinitely then I'm content.
counts (and I have been there, too, even before this exchange).
light+love,
Mike
Mike Gabriel
Apr 6, 2018, 8:50:02 AM4/6/18
to
Hi Simon,
some interim results...
On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895025
(see the blocking bugs there, too)
For src:libindicate-qt:
already removed from testing/unstable, only still in oldstable, though.
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
some interim results...
On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
> * 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)
For src:libindicate:
> by RC bugs "should not be released with buster" and/or ftp.debian.org
> RM bugs)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895025
(see the blocking bugs there, too)
For src:libindicate-qt:
already removed from testing/unstable, only still in oldstable, though.
Mike
--
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.g...@das-netzwerkteam.de, http://das-netzwerkteam.de
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
Mike Gabriel
Apr 6, 2018, 9:30:02 AM4/6/18
to
Hi again,
On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
libappindicator package is a key-package (high popcon value) so it
probably won't be removed from testing before a considerate amount of
porting work (over the libayatana-appindicator) has been done.
libappindicator:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895037
libindicator:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895038
ido:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895039
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
On Do 29 Mär 2018 15:54:26 CEST, Simon McVittie wrote:
> * deprecated but still supported (preferably documented by an upload
> and/or ftp.debian.org bug overriding their Section to oldlibs)
I filed RC bugs now against libappindicator and libindicator. The
> and/or ftp.debian.org bug overriding their Section to oldlibs)
libappindicator package is a key-package (high popcon value) so it
probably won't be removed from testing before a considerate amount of
porting work (over the libayatana-appindicator) has been done.
libappindicator:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895037
libindicator:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895038
ido:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895039
Mike
--
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.g...@das-netzwerkteam.de, http://das-netzwerkteam.de
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
Clément Hermann
Apr 6, 2018, 10:20:02 AM4/6/18
to
On 29/03/2018 15:11, Mike Gabriel wrote:
> [stuff]
Thanks for this summary and your work on this.
> ### Ayatana AppIndicator API
>
> The Ayatana AppIndicator API is just one way of talking to an SNI DBus
> service. The implementation is done in the shared lib
> 'libayatana-appindicator'. This library provides an easy to implement
> API that allows GTK-2/3 applications to create an indicator icon in a
> panel with an indicator renderer added.
>
> In the application, the developer creates a generic menu structure and
> defines one or more icons for the system tray (more than one icon: only
> one icon is shown (plus some text, if needed), but that icon may changed
> based on the applet's status). This generic menu is sent to a DBus
> interface (org.kde.StatusNotifier). Sometimes, people say, that such
> applications have SNI support (StatusNotifier Interface support).
>
> The Ayatana Indicators project offers Ayatana AppIndicator to GTK-3
> developers (and GTK-2, but well...). Canonical implemented bindings for
> Python2, Perl, GIR, Mono/CLI and we continue to support these as long as
> it makes sense.
That sounds interesting. I maintain openpgp-applet [0] (both upstream
and in debian, which is in perl / gtk3 and currently uses the old
fashion systray.
However, I did a quick search, and I couldn't find the bindings for perl
you speak about, be it on CPAN or Launchpad. I probably missed it,
could you share a link ?
> 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.
>
> In Debian, we will start sending out patches too SNI supporting
> applications soon, that make the shift from Ubuntu AppIndicator (badly
> maintained in Debian) to Ayatana AppIndicator. The cool part of this is,
> you can convert your GTK-3 application from Ubuntu AppIndicator to
> Ayatana AppIndicator and use it on top of any(!) SNI implementation, be
> it an applet based on Ubuntu Indicators, based on Ayatana Indicators or
> some other implementation, like the vala-sntray-applet or SNI support in
> KDE.
I remember reading somewhere that a limitation is that you can only use
one type of click (no way to behave differently on right-click /
left-click), so I guess in some cases the switch means also a new UI,
right ?
Cheers,
[0] https://tracker.debian.org/openpgp-applet, and
https://openpgp-applet-team.pages.debian.net for the upstream
project
--
nodens
> [stuff]
Thanks for this summary and your work on this.
> ### Ayatana AppIndicator API
>
> The Ayatana AppIndicator API is just one way of talking to an SNI DBus
> service. The implementation is done in the shared lib
> 'libayatana-appindicator'. This library provides an easy to implement
> API that allows GTK-2/3 applications to create an indicator icon in a
> panel with an indicator renderer added.
>
> In the application, the developer creates a generic menu structure and
> defines one or more icons for the system tray (more than one icon: only
> one icon is shown (plus some text, if needed), but that icon may changed
> based on the applet's status). This generic menu is sent to a DBus
> interface (org.kde.StatusNotifier). Sometimes, people say, that such
> applications have SNI support (StatusNotifier Interface support).
>
> The Ayatana Indicators project offers Ayatana AppIndicator to GTK-3
> developers (and GTK-2, but well...). Canonical implemented bindings for
> Python2, Perl, GIR, Mono/CLI and we continue to support these as long as
> it makes sense.
and in debian, which is in perl / gtk3 and currently uses the old
fashion systray.
However, I did a quick search, and I couldn't find the bindings for perl
you speak about, be it on CPAN or Launchpad. I probably missed it,
could you share a link ?
> 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.
>
> In Debian, we will start sending out patches too SNI supporting
> applications soon, that make the shift from Ubuntu AppIndicator (badly
> maintained in Debian) to Ayatana AppIndicator. The cool part of this is,
> you can convert your GTK-3 application from Ubuntu AppIndicator to
> Ayatana AppIndicator and use it on top of any(!) SNI implementation, be
> it an applet based on Ubuntu Indicators, based on Ayatana Indicators or
> some other implementation, like the vala-sntray-applet or SNI support in
> KDE.
one type of click (no way to behave differently on right-click /
left-click), so I guess in some cases the switch means also a new UI,
right ?
Cheers,
[0] https://tracker.debian.org/openpgp-applet, and
https://openpgp-applet-team.pages.debian.net for the upstream
project
--
nodens
Ian Jackson
Apr 6, 2018, 10:50:02 AM4/6/18
to
Clément Hermann writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
If that is a problem for a particular applet, then it can be avoided
by continuing to use the xembed protocol.
I'm not sure what library would be recommended for such an applet.
Mike, can you advise ?
> On 29/03/2018 15:11, Mike Gabriel wrote:
...
> > 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.
...
> > 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.
> I remember reading somewhere that a limitation is that you can only use
> one type of click (no way to behave differently on right-click /
> left-click), so I guess in some cases the switch means also a new UI,
> right ?
Yes, that has been confirmed in this thread.
> one type of click (no way to behave differently on right-click /
> left-click), so I guess in some cases the switch means also a new UI,
> right ?
If that is a problem for a particular applet, then it can be avoided
by continuing to use the xembed protocol.
I'm not sure what library would be recommended for such an applet.
Mike, can you advise ?
Mike Gabriel
Apr 6, 2018, 4:50:02 PM4/6/18
to
HI Clément,
There is no direct Perl module, but the libayatana-appindicator shared
lib has gir1.2-ayatanaappindicator-0.1. So you should be good when
using GIO in Perl, if you are on GTK3 already. (The
perl-Gtk2-Appindicator module has indeed been recently removed from
Debian to discourage work on appindicator based on GTK2).
>> 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.
>>
>> In Debian, we will start sending out patches too SNI supporting
>> applications soon, that make the shift from Ubuntu AppIndicator (badly
>> maintained in Debian) to Ayatana AppIndicator. The cool part of this is,
>> you can convert your GTK-3 application from Ubuntu AppIndicator to
>> Ayatana AppIndicator and use it on top of any(!) SNI implementation, be
>> it an applet based on Ubuntu Indicators, based on Ayatana Indicators or
>> some other implementation, like the vala-sntray-applet or SNI support in
>> KDE.
>
> I remember reading somewhere that a limitation is that you can only use
> one type of click (no way to behave differently on right-click /
> left-click), so I guess in some cases the switch means also a new UI,
> right ?
Yes. With GTK3 you would implement the Xembed based systray icon with
GtkStatusIcon and attach a GtkMenu to that.
This allows left click and right click.
With AppIndicator, you will use the API provided by
libayatana-appindicator for creating your systray icon. For now, we
have to use Ubuntu's docs (it is on my todo list to port the
implementation examples over to the Ayatana Indicators' web site) [1].
Unfortunately, the porting guide has no Perl example, but with GIO
this should be easily transferable from e.g. Python code examples.
If you want to provide support for GtkStatusIcon and Ayatana
AppIndicator, you may want to study the transmission-gtk code [2]
(written in C, though).
You could also drop the GtkStatusIcon based implementation entirely
and fully switch over to Ayatana AppIndicator. When doing that, you
loose the right-click menu (I must re-check that, if that is really
fully true). On desktops that don't provide the StatusNotifierItem
interface, your application will fallback to Xembed.
Staying with Xembed-only support is IMHO not recommendable, because
e.g. GNOME (and derivatives) are continuously discussing the removal
of Xembed support in their desktop env.
>
> Cheers,
>
> [0] https://tracker.debian.org/openpgp-applet, and
> https://openpgp-applet-team.pages.debian.net for the upstream
> project
light+love,
Mike
[1]
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Porting_Guide_for_Applications
[2] https://sources.debian.org/src/transmission/2.92-3/gtk/tr-icon.c/#L138
lib has gir1.2-ayatanaappindicator-0.1. So you should be good when
using GIO in Perl, if you are on GTK3 already. (The
perl-Gtk2-Appindicator module has indeed been recently removed from
Debian to discourage work on appindicator based on GTK2).
>> 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.
>>
>> In Debian, we will start sending out patches too SNI supporting
>> applications soon, that make the shift from Ubuntu AppIndicator (badly
>> maintained in Debian) to Ayatana AppIndicator. The cool part of this is,
>> you can convert your GTK-3 application from Ubuntu AppIndicator to
>> Ayatana AppIndicator and use it on top of any(!) SNI implementation, be
>> it an applet based on Ubuntu Indicators, based on Ayatana Indicators or
>> some other implementation, like the vala-sntray-applet or SNI support in
>> KDE.
>
> I remember reading somewhere that a limitation is that you can only use
> one type of click (no way to behave differently on right-click /
> left-click), so I guess in some cases the switch means also a new UI,
> right ?
GtkStatusIcon and attach a GtkMenu to that.
This allows left click and right click.
With AppIndicator, you will use the API provided by
libayatana-appindicator for creating your systray icon. For now, we
have to use Ubuntu's docs (it is on my todo list to port the
implementation examples over to the Ayatana Indicators' web site) [1].
Unfortunately, the porting guide has no Perl example, but with GIO
this should be easily transferable from e.g. Python code examples.
If you want to provide support for GtkStatusIcon and Ayatana
AppIndicator, you may want to study the transmission-gtk code [2]
(written in C, though).
You could also drop the GtkStatusIcon based implementation entirely
and fully switch over to Ayatana AppIndicator. When doing that, you
loose the right-click menu (I must re-check that, if that is really
fully true). On desktops that don't provide the StatusNotifierItem
interface, your application will fallback to Xembed.
Staying with Xembed-only support is IMHO not recommendable, because
e.g. GNOME (and derivatives) are continuously discussing the removal
of Xembed support in their desktop env.
>
> Cheers,
>
> [0] https://tracker.debian.org/openpgp-applet, and
> https://openpgp-applet-team.pages.debian.net for the upstream
> project
Mike
[1]
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Porting_Guide_for_Applications
[2] https://sources.debian.org/src/transmission/2.92-3/gtk/tr-icon.c/#L138
Ian Jackson
Apr 9, 2018, 9:30:03 AM4/9/18
to
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
For all the reasons which have been discussed in this thread, it is
necessary to retain Xembed support indefinitely.
Ian.
> Staying with Xembed-only support is IMHO not recommendable, because
> e.g. GNOME (and derivatives) are continuously discussing the removal
> of Xembed support in their desktop env.
This is alarming.
> e.g. GNOME (and derivatives) are continuously discussing the removal
> of Xembed support in their desktop env.
For all the reasons which have been discussed in this thread, it is
necessary to retain Xembed support indefinitely.
Ian.
Mike Gabriel
Apr 10, 2018, 9:00:02 AM4/10/18
to
Hi Ian,
this is beyond my/our ways of impact.
The systray support [1] for Ayatana Indicators will be a system
indicator applet.
The system indicators will be available to desktop envs that support
them (currently MATE, XFCE, Budgie). But all of those also support
Xembed natively.
The GNOME desktop does not support system indicators. Plus, Xembed
support is also very weak. And application indicators seem to be on
the verge from time to time, too. Please express your worries to the
GNOME upstream / downstream devs in this respect.
Fully in line with you feeling troubled, but it is others that need to
notice, I guess.
Mike
[1] https://github.com/AyatanaIndicators/ayatana-indicator-systray
The systray support [1] for Ayatana Indicators will be a system
indicator applet.
The system indicators will be available to desktop envs that support
them (currently MATE, XFCE, Budgie). But all of those also support
Xembed natively.
The GNOME desktop does not support system indicators. Plus, Xembed
support is also very weak. And application indicators seem to be on
the verge from time to time, too. Please express your worries to the
GNOME upstream / downstream devs in this respect.
Fully in line with you feeling troubled, but it is others that need to
notice, I guess.
Mike
[1] https://github.com/AyatanaIndicators/ayatana-indicator-systray
Ian Jackson
Apr 10, 2018, 10:00:02 AM4/10/18
to
Mike Gabriel writes ("Re: Upcoming shift to Ayatana (App)Indicator(s)"):
> The GNOME desktop does not support system indicators. Plus, Xembed
> support is also very weak. And application indicators seem to be on
> the verge from time to time, too. Please express your worries to the
> GNOME upstream / downstream devs in this respect.
Can you point me to the right place to make my point ?
> support is also very weak. And application indicators seem to be on
> the verge from time to time, too. Please express your worries to the
> GNOME upstream / downstream devs in this respect.
Thanks,
Ian.
Mike Gabriel
Apr 13, 2018, 7:40:03 PM4/13/18
to
Hi Ian,
I'd think you should direct your point to upstream themselves:
https://www.gnome.org/contact/
And the Debian GNOME team is quite involved, too, so you may want to
get in touch with people on debian-gnome ML or IRC.
Greets,
Mike
https://www.gnome.org/contact/
And the Debian GNOME team is quite involved, too, so you may want to
get in touch with people on debian-gnome ML or IRC.
Greets,
Mike
0 new messages