[Linux] Use more specific & more integrated alternatives for status icon

[csoriano1618]

Hello,

Carlos from Linux & GNOME here. We are trying to approach important apps using status icons to provide better alternatives that are more integrated with the system. Status icons have been deprecated for some time and we plan to remove the systray for GNOME 3.26.

Currently Telegram uses status icon for:

1. Notify of incoming messages
2. Quit application
3. Disable notifications
4. Minimize to tray
5. Open app

For 1, the proper approach is to use native notifications. Telegram has a setting for this, but it's off by default. The solution would be to enable this on by default, so the user benefits from the notification integration. This will allow the user to see whether the user has any pending messages in a permanent place, and also disable notifications if desired in a grained way. I filed issue #3831 separately to discuss the notification implementation. Documentation for native notifications can be found here. For 2, the recommended approach is to ask the user if the application should run in the background the first time it click the close button, then enable a setting with "run in the background". The user can deactivate it anytime if changes user's mind. An example would be Polari, and IRC client. The dialog looks like:

For 3, would be fixed with 1, and will use the system wide settings and integration for notifications, instead of something for every app in the system. For 4, won't be needed if 2 is implemented. For 5, it happens when a notification is clicked, or if the app is run again from the recent app list or from any place where apps can be searched & run

Something to note here is that these solutions are cross-desktop, so it should work for any Linux distribution.

Let me know what do you think and feel free to ask any question!

Thanks

[stek29]

Quit application

Ctrl+Q

Disable notifications

It's in settings

[fbruetting]

@csoriano1618 I’m wondering, what the GNOME view of the message aggregation indicator of Unity is? Since messages are usually more important than other (non-permanent) notifications, one can separate urgent cases from the minor ones. Also this would target a whole class of use cases (mails, instant messages, IRC, Twitter, etc. pp.). The benefits I see are:

• Not as crowded as a list of mixed notifications about all kinds of things in the notification center.

• For instant messaging services, people usually respond very quickly – while most people (I know of) just look sparsely into the notification center. Missing instant messaging notifications prevents messaging being instant.

• One should be able to mark notification sources as inactive. E.g. receiving E-Mails should not light up the message indicator, because most mails are not that important. You should still see the number of unread mails of every mail account when you click the indicator, but this way you won’t be compelled clicking the indicator. Received instant messages should indeed light it up like it’s done on everybody’s mobile – but this won’t be as obtrusive as a notification popping up. One then would be able seeing all unread messages of all sorts of messaging sources all together in a clean and unified way.

• I think that communication is so important, that it deserves it’s own icon in the top panel. Maybe this aggregation could be implemented inside the notification center, instead of making up a separate indicator, but communication overview should really be separated from other notifications.

• This approach could solve all mentioned issues and introduce more coherence into desktop environments when a corresponding libmessaging could be provided, like this new libcloudproviders.

[diazbastian]

@csoriano1618 I would also like to see native notifications by default, but currently Telegram notifications offer better features. On the other hand there is no native solution for voice calls (eg something similar to the implementation of MPRIS in Gnome, where you can accept/deny a call and view its status persistently without go to the app window) . The above example would also work for any other voice and video application (Ring, Skype, Viber, Gajim, Jitsi, etc.).

Note: You may be interested in the ticket 279 of transmission.

[csoriano1618]

Thanks for the feedback and questions so far. I'll answer them soon, I'm evaluation the questions with our designers and other developers to provide accurate answers, sorry for taking long :)

[Aokromes]

2191 ?

[aruiz]

Hey @csoriano1618, any progress on this? :-)

[csoriano1618]

Hey,

Sorry for the late answer. Indeed, Telegram has a good point that native notifications doesn't implement an easy way to reply inline. GNOME actually wants that too, so it's a matter of working on extending the protocol.

[cold-distance]

Hi, I saw this bug report so I will take it to make a suggestion.

I use Fedora with GNOME with vanilla experience now, so I don't have status icons or systray.

It would be wonderful if Telegram Desktop could be closed only with the close button. The only thing needed is to have an option in settings to disable systray/status icon support at least for Linux.

[jhasse]

There is.

[fbruetting]

@csoriano1618 What about your answers? :P

Thanks for the feedback and questions so far. I'll answer them soon, I'm evaluation the questions with our designers and other developers to provide accurate answers, sorry for taking long :)

[csoriano1618]

Hey,

I was rereading now the comments. I think I answered the most important one, which is what about inline reply. Last time we discussed it we indeed wanted that, and we would like to extend the protocol to include it if possible.

For the design of the "notification center" in GNOME Shell, that's probably not very important here, since it's up to the DE how to interpret those notifications. That probably isn't much of a requirement either, since Telegram doesn't implement the proposed design currently either.

On the other hand there is no native solution for voice calls

Wouldn't a notification with two actions (accept, deny) be the solution for this?

Is there anything I'm missing? I'll be glad to get an answer for those.

[fbruetting]

Ah, I thought you can speak for Gnome about a messaging center concept. 😄

[diazbastian]

Wouldn't a notification with two actions (accept, deny) be the solution for this?

@csoriano1618 Maybe, but I was referring to an implementation more similar to that found on mobile devices (persistent notification). For example in Android, if we don't answer immediately or we are occupying another app, you can accept a call from a notification or the notification center, the same to stop or cancel a call. This also applies to other apps that include calls and allow you to do this without having to bring the app to focus. The most common options are accept/decline /mute microphone.

[csoriano1618]

This also applies to other apps that include calls and allow you to do this without having to bring the app to focus.

Yeah that makes sense, there has been some discussion about putting actions on the notification center.

I'm not sure this is in scope of this issue tho... the native notification issue is at https://github.com/telegramdesktop/tdesktop/issues/3831. But also, Telegram notifications cannot do this kind of thing right now either, it would need collaboration with the DE, and indeed it would be amazing to improve that. With this issue I'm more focusing in covering what the current Telegram notifications provide and make sure those are ok, so Telegram can transition to native notifications without big issues.

[github12101]

Two years and still not fixed? What is going on?

[GabVenturato]

@Aokromes @csoriano1618 I think the problem now is that in Gnome (I am referring to my experience in Fedora 30, you can read more in che closed issue referred above) I have no option to have telegram closed when the close button is pressed! If I want to close telegram I have to kill the process by CLI. Is there a fix for this? Because it seems to me that the situation is a bit neglected.

[jhasse]

@GabVenturato "Settings" -> "Advanced" -> Uncheck "Show tray icon"

edit: after reading #6412 I understand your problem: The option isn't there for you in GNOME.

[cold-distance]

@GabVenturato "Settings" -> "Advanced" -> Uncheck "Show tray icon"

edit: after reading #6412 I understand your problem: The option isn't there for you in GNOME.

I just checked and I see that the problem persists. It's very annoying.

[GabVenturato]

@jhasse yeah, that's exactly the problem

[DarkFenX]

6692 was created by me. Needless to say, I am annoyed by lack of tray icon.

My use-case: I use telegram at work as IM for personal purposes. So, I keep it open, with tray icon shown (via TopIcons). When I focus on my task - I do not want any kind of popups to distract me (let alone fellow coworkers looking at content of notifications, should they look at my display). However, when I have a moment, I take a look at the tray and see if there're any unread discord/telegram notifications (indicator is handled by apps themselves - it allows to filter out muted chats which i consider completely irrelevant while I am at work; I check them very rarely by opening full app).

And it worked just fine, until today.

@csoriano1618, how should I approach my use-case within "new" gnome paradigm?

edit: Another use-case. It also might be good to indicate status of various apps. For example, I have set up synchronization of data for several apps via dropbox. When I am using this app, it constantly changes said data and dropbox syncs it with cloud. Status icon shows if dropbox is in process of a sync or not; when finishing my work, I look at its status. Once data is synced, I put my PC to sleep. When I come back, I wake the PC up, wait for data to sync and then launch app once again (to avoid sync conflicts).

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[ilya-fedin]

It seems no one stopped stale bot from closing the issue despite it's apparently not fixed as duplicates of this issue are being still created... Sadly, there's still no progress in solving this, I've tried multiple approaches, but all of them lead into problems due to the lack of APIs.

Since then, native notifications became the default based on supported capabilities of the notification daemon, the currently required capabilities (body, actions, inline-reply, inhibitions) practically mean native notifications are default only on KDE as it's the only server implementation supporting all of them. Here's what I tried and what could help to make native notifications the default on GNOME:

1. The most obvious solution of using the sound capability and letting the server playing the sounds runs into the fact notifications daemons accept only WAVs while Telegram supports mp3 and wav files which are being downloaded from the cloud, so they have to be re-encoded on the fly and sadly there's no one who have both time and knowledge at the same time in tdesktop project to implement a re-encoder. This hasn't happen for 6 years and I'm highly doubt this can ever happen unless GNOME project provides help with code.
2. I've tried to make the use of the sound-name hint to play the sound provided by the system, but as it happened the spec guarantees only support for sound-file and suppress-sound hints with that capability which turns this into a no-go. I've reported that at xdg-specs two years ago and even created a MR both of which are ignored. Maybe GNOME can get attention to those?
3. The simplest solution for tdesktop would be for GNOME to support both inhibitions and inline-reply as that would mean zero code changes from tdesktop side.

The problem with running in background is still valid as well and there's no permission from the designers to add such a dialog AFAIK. Possible solution is to use the macOS code path where it's assumed it's native to the system to run in background and it will automatically detect the app is still running and provide a way to close it (e.g. with an icon in the dock as macOS does). The problem here is we need an API to know that the DE prefers apps to run in background, something like a property on org.freedesktop.portal.Settings would fit pretty nice.

@csoriano1618 are you still interested in solving this? Can you provide help with code or standardizing the APIs and having them implemented on GNOME side?

[ilya-fedin]

Ah, forgot to mention that I also attempted to use GNotifcation. I thought it would be nice to use it to support the portal notifications (as its documentation is poor) and I saw it also supports some proprietary GNOME spec, so I thought maybe it's something GNOME applications use to provide the good UX with sounds. After getting notifications implemented on top of GNotification, I understood that it doesn't support sounds at all with frustrating finding that GNOME doesn't want to support sounds, but it does via the freedesktop spec what makes GNotification an outsider in comparison to the freedesktop spec (and there's a hidden feature that makes the use of sound-name when the play sound tdesktop option is off), as a result GNotification is used only in flatpak and only when the freedesktop protocol is not available. As GNotification doesn't provide a way to detect whether there's any protocol support, it's not possible to use it by default in all cases. It also doesn't support:

1. Images via path for the portal
2. Images via bytes for the freedesktop spec

What means it's not a good API to use by default in general, as there's always a chance someone won't see the avatar as it's not possible to set bytes and path at the same time. Btw, while glib can't use gdk-pixbuf, I believe it can at least create a temporary file from the bytes for the freedesktop spec.

I don't really understand how GNOME messengers provide good UX with notifications, do GNOME users like when there's no sound on incoming message? As I'm highly doubt tdesktop userbase, even the one that is using GNOME, will appreciate some blacklist to not to play sound on GNOME.

[AsciiWolf]

On Linux systems without an AppIndicator / KStatusNotifierItem support (for example Fedora Workstation), Telegram Desktop seems to always quit when its main window is closed. Enabling the "Show tray icon" option in Telegram Desktop Advanced Settings results in the main Telegram Desktop window reopening every time it is closed.

Please, consider adding a better approach for these systems. At least in the Flatpak version of Telegram Desktop (there is a new background portal along with background apps support in GNOME 44).

(By the way, the GNOME 44 Background Apps dialog also supports status notifications.)

For non-Flatpak version, at least allow this app to run on background on systems with no AppIndicator support and opening the window for this running session on subsequent runs of Telegram Desktop.

Other possible solution is to wait until GNOME actually has a proper AppIndicator support. This can never happen and it is not ideal to force stock GNOME users to keep their Telegram Desktop window opened all the time.

[ilya-fedin]

@AsciiWolf please read the previous posts in the thread, we need APIs from GNOME side (& to be standardized) in order to run in background without window. However, there's already "Close to taskbar" option that lets Telegram run in background right now using cross-platform APIs to hide the window instead of destroying it.

[AsciiWolf]

What I am talking about is support for Telegram to run on background on systems without AppIndicator / KStatusNotifierItem support (or did you mean other APIs?). For example Steam from Valve seems to run fine on background even on a stock GNOME and when subsequently launching the Steam client, window for the active session that is running on background gets opened. At least this is how it worked the last time I tried it on a stock GNOME system. Telegram is the main reason I am still having the (buggy) AppIndicator extension enabled on all my GNOME systems.

[ilya-fedin]

@AsciiWolf Electron doesn't have API to check tray presence, so I assume they have a bug of running in background with no way for the user to quit the application (e.g. some lightweight window manager environment without tray support and without desktop actions support). Telegram being a Qt application can act correctly in that case and acts. I don't think we should leave those users without a way to quit in the sake of GNOME users convenience (implementing a feature request while adding a bug). Actually, I've explained that all in older messages in the thread, please read them and don't make me to repeat all that again & again.

[lucacarpizzo836]

@ilya-fedin I think there's some misunderstanding going on here. GNOME 44 has added support for background apps, what's preventing the implementation of that feature into the app?

[jtojnar]

@lucacarpizzo836 that is currently only implemented for Flatpak apps, see https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3699

[AsciiWolf]

The plan as far as I know is to extend the background portal to also support non-sandboxed apps in the future. Anyway, as I already mentioned in my previous comment, Telegram does not need to support the background portal API directly, it just needs to be able to continue running on background (even without the AppIndicator icon) after its main window gets closed + to be able to restore the background session when subsequently launching Telegram.

[ilya-fedin]

what's preventing the implementation of that feature into the app?

As I already said, we need API to know whether the environment prefers applications running in background to closing them, as Telegram designers don't give a permission to implement a dialogue like proposed here in first post, so we need a solution adding zero new UI elements to tdesktop. Such API is the only way I can see. So we can re-use the macOS codepath when such API returns true.

[AsciiWolf]

As far as I know, the dialog from the first post does not have to be implemented by the app itself. See for example this part of the xdg-desktop-portal code.

[AsciiWolf]

https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Background https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Request

Here is a related documentation of the XDG Desktop Portal API.

[ilya-fedin]

The API has no "Supported" method and I have the D-Bus interface on Plasma (while I know for sure it has no UI for background apps) so the presence of the interface itself doesn't say anything about support either. So this is not the API I was describing.

Basically, we need a way to ensure the user sees the quit button, so it may be not an API to check whether the environment prefers applications running in background but an API to check whether Desktop Actions are supported by the environment. But I don't see such an API either.

[AsciiWolf]

It is also supported on Plasma, see: https://github.com/KDE/xdg-desktop-portal-kde/blob/master/src/background.cpp

I may be wrong, but I think that it also is somehow supported on non-GNOME/non-KDE environments by directly using the xdg-desktop-portal (not relying on xdg-desktop-portal-gnome or xdg-desktop-portal-kde).

[ilya-fedin]

@AsciiWolf I don't see any indicator that application is running in background (and quit it), not sure we can say it's really supported

[ilya-fedin]

I'm doubt the presence of background portal means 'this environment prefers applications to run in background and is obligated to provide a background indicator, desktop actions or other means to let the user quit the application'.

[AsciiWolf]

There should be a notification. See for example this thread: https://www.reddit.com/r/kde/comments/11ul75n/is_there_a_way_to_disable_this_running_in_the/

[ilya-fedin]

The notification won't allow me quit the application. Moreover, it's discarded and you have no indicator. It also doesn't discard itself when application quits.

[AsciiWolf]

Clicking "Find out more" should allow you to force quit the app. I agree that the KDE implementation may not be ideal (but will hopefully improve over time), but it works. And using this background portal (at least optionally) would, in my opinion, still be much better than shipping the Telegram app in a broken state to all stock GNOME users.

[ilya-fedin]

I looked at the portal documentation, it's just to request background permission in flatpak (which seem to be automatically granted atm so no use of the API is needed) and has nothing to do with

this environment prefers applications to run in background and is obligated to provide a background indicator, desktop actions or other means to let the user quit the application

[AsciiWolf]

I don't use Plasma so I am not sure what the implementation there exactly looks like.

[ilya-fedin]

than shipping the Telegram app in a broken state to all stock GNOME users.

The key problem is the lack of contributors. I'm the only one Linux user contributing to tdesktop and I'm a Plasma user, I have no idea how applications should work on GNOME. For Telegram to be not broken on GNOME, someone from the GNOME community with the knowledge how applications should work there has to step up and contribute fixes for Telegram for it to be no more broken. There's even no contributor to do that.

[ilya-fedin]

I don't use Plasma so I am not sure what the implementation there exactly looks like.

Not sure what you mean. I talk about documentation provided by the links you provided

org.freedesktop.portal.Background — Portal for requesting autostart and background activity

[ilya-fedin]

Clicking "Find out more" should allow you to force quit the app.

It provides the dialog to grant or reject the permission, that's not what I'm talking about. I'm talking about quitting the application while already running in background cause the app has no way to quit in the UI (and no one would allow to add it).

[ilya-fedin]

Another way out of this is push notifications so tdesktop doesn't have to run in background at all. But there seem to be no news about push notifications API either...

[AsciiWolf]

Not sure what you mean. I talk about documentation provided by the links you provided

As far as I know, the Background portal (and also its implementation in xdg-desktop-portal-gnome) was extended when the new "Background Apps" dialog was implemented in GNOME 44. See for example this ticket.

[ilya-fedin]

If I understand your link right, they just added a way for the portal implementation to know which sandboxed applications are running. This has nothing to do with

this environment prefers applications to run in background and is obligated to provide a background indicator, desktop actions or other means to let the user quit the application

[AsciiWolf]

They added a way for the portal implementation to know which sandboxed applications are running on background and communicating this to a host system via D-Bus.

I am however not sure whether the Background portal can detect if the "environment prefers applications to run in background" and can pass this information to the application via API.