Re: I believe we should reconsider our sys-tray removal

How does KDE deal with appindicators? Is there something we could partner with then on? Are they trying to solve this also? 

Did KDE modify the spec? Not knowing much about the nuance of the different indicator solutions, my experience with kstatusnotifier has been fairly great. 5/6 icons show up there as they should (I think discord is the only one that doesn't) and the theme on the drop-down menu when clicking matches the shell theme perfectly. This is in contrast to TopIcons/Plus/Redux that shows all of the icons, but the drop-down themeing is terrible.

A couple of thoughts on my mind that maybe someone can answer:

1) When an application has an open window there is a notification dot on the dash to show that it is open. However, when the app window is closed but the process is still running, I.e. steam, telegram, etc, there is no dot to indicate visually that the app is still open. Why is this? On OSX they keep the dot up until the app is fully quit.

2) Back in early GNOME3 we had the slide up tray from the bottom. Am I the only one who thought that was super cool? It had nice big icons for touch and accessibility purposes, and it was just really cool looking imo. I was sad when that went away for usability reasons. Is there any chance on resurrecting that and polishing it's usability issues as a solution?

3) realistically what are the chances of us working with the other interested parties and creating a functional/unified spec once and for all. We could do the whole Mantle-->Vulkan transition with appindicator-->XDG-appicon or something of the sort. My dream is to create a solution for everyone, not just GNOME

On Mon, Mar 25, 2019 at 11:39 AM Emmanuele Bassi via desktop-devel-list <desktop-devel-list gnome org> wrote:

On Mon, 25 Mar 2019 at 18:27, Florian Müllner <fmuellner gnome org> wrote:
On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi <ebassi gmail com> wrote:
> You cut the part where I said the appindicator implementation should be changed. :-)

I thought you were referring to the client library, not the underlying spec :-)

AFAIK the spec still assumes X11 like:


UINT32 org.freedesktop.StatusNotifierItem.WindowId ();

It's the windowing-system dependent identifier for a window, the application can chose one of its windows to be available through this property or just set 0 if it's not interested.


or DBus-Menu:



OBJECT PATH: DBus path to an object which should implement the com.canonical.dbusmenu interface


on top of the whole wishy-washy "don't implement this if you don't like it, Mercury is retrograde, or it's Thursday", so it's definitely needs to be changed as well.


desktop-devel-list mailing list
desktop-devel-list gnome org

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