Tdesktop: Keep Telegram running in the background when no system tray is available

Created on 16 Aug 2020  路  30Comments  路  Source: telegramdesktop/tdesktop

On operating systems such as elementaryOS, there is no system tray available. Instead, apps are expected to keep the dock icon shown even if all the app windows are closed.

On elementaryOS, Telegram Desktop doesn't run in the background (leading it to not deliver notifications for obvious reasons) since it doesn't see the tray available. Once installing a hack (something that should not be needed) to get the tray somewhat in the system, Telegram Desktop runs in the background once again.

3rd party issue

All 30 comments

Just minimize instead of closing

Just minimize instead of closing

Quite inconvenient, especially since the system by design hides the minimise button like GNOME 3 does.

Well, GNOME & elementaryOS should stop making a separate platform and just implement the tray like all other DEs, unless they want to be incompatible with apps that aren't a part of their platform and don't want to follow their HIG.

I also don't see why this is a 3rd party issue considering this behaviour happens because Telegram Desktop expects some deprecated APIs to be available. The fix should be simple (though it's code so it's never simple): keep Telegram running even if the system tray is unavailable. Perhaps add an option for that in Settings.

Telegram Desktop does not shut down when the window is closed on macOS according to macOS HIG. Why can't this behaviour be enabled on GNOME & Co. as well?

Tray is not a deprecated API (even if gnomers want to be so)

It is on GNOME and derivatives. And heavily discouraged on macOS when the sole purpose is to keep the app active, since that's what the dock icon is for. Again, why can't the macOS behaviour, which is what is expected on GNOME, be enabled on GNOME as well?

It is on GNOME and derivatives

As I said:

even if gnomers want to be so

Again, why can't the macOS behaviour, which is what is expected on GNOME, be enabled on GNOME as well?

Telegram Desktop is not a GNOME app and shouldn't follow GNOME guidelines. It is better to follow DE-neutrality.

Then why does Telegram Desktop work as expected on macOS instead of shutting down when the window is closed?

macOS is OS, GNOME is just a DE

Technically, Linux has no graphical user interface to begin with if we dig that deep into details, X11 or Wayland being extra bits added on top.

Regardless of it being an OS, not just a DE, it is still a different platform for which Telegram Desktop exhibits customised behaviour in order to satisfy the expectations of how a properly working software should behave. Yet expanding that customised behaviour to another platform with the same requirements suddenly isn't okay.

Technically, Linux has no graphical user interface to begin with if we dig that deep into details, X11 or Wayland being extra bits added on top.

That's why tdesktop doesn't have any customized behavior for any of DEs on Linux.

First, I don't see how the quote justifies the reasoning for not having customised behaviour.

But then sure, back to my other proposal: add an option in settings to keep the app running even if there is no system tray available, so it can still deliver notifications. That option won't be DE specific, it will be available for anybody to use.

There are already an issue for that: #1161

Only somewhat related, since that issue mentioned that the close button would minimise the app. What I want is for the window to not be there anymore, including in Alt+Tab, but for the app to be running in the background to deliver notifications.

What I want is for the window to not be there anymore

I don't think this is a good option, there are should be some sign of presence.

Better than not receiving notifications or having the window cluttering my Alt-Tab.

On mobile operating systems, there is no sign of presence that the device is checking for notifications. I don't see why there must be a sign of presence on desktop?

Is it nice to have? Sure. Is needing a sign of presence worth a worse experience (app loads slower when starting up from being closed, no notifications delivered)? I would say no.

Furthermore, this would certainly be opt in. So it would be up to me when turning on the option to decide if it's a good option or not.

As you can see by #897, #1161, #2060 (even a PR adding this option was rejected), options are not created in this project unless there are a very-very-very big issue. Is seems your issue is not that big :).

  • [X] Show tray icon
  • [ ] Use system window frame
  • [ ] Launch minimized

Those options certainly do not seem "very-very-very big" issues.

At this point, especially considering one of the devs complained about code not being submitted yet PRs are rejected as well, this feels like a traditional case of "we do only what we want and the users we are supposed to write this application for can ...".

It happens, and it sucks, especially when people want to improve and even write the code that afterwards gets rejected.

Those options certainly do not seem "very-very-very big" issues.

You're wrong. "Use system window frame" was added after a lot of complains from tiling users. The first and the last were from the first tdesktop release IIRC.

Why customise for tiling DEs but not for GNOME then?

Why customise for tiling DEs but not for GNOME then?

Because titlebar on a tiling WM is a big window managing issue, while behavior without tray icon is not

+ tiling WMs is a class of WMs while GNOME and Pantheon are still just two DEs

That's why tdesktop doesn't have any customized behavior for any of DEs on Linux.

Judging by your quote above, so what?

Turns out you do have customised behaviour for some DEs, just not for GNOME derivatives.

So, once again, it's a case of "we only do what we want" and probably combined with a grudge against GNOME.

At this point, I know I'm not going to change anything. But the reasons for denying my proposed improvement seem more and more to be "GNOME can go ...", and then after the decision is made some justification to make it look nicer is made up.

Or at least that's what it seems judging by all the inconsistencies in the reasons given.

Judging by your quote above, so what?

WM != DE

WMs just provide a way to control windows, it is not a specific integration option for DE

And I repeat that the main reason for this option was a lot of complains on #2958

it is not a specific integration option

Providing an option to display the native title bar is a specific integration option.

And I repeat that the main reason for this option was a lot of complains on #2958

You just said a couple of replies above that even if there are a lot of complaints PRs are still refused. So yeah, I don't see the point in this reply.


I'll leave the discussion by leaving this article here: https://computinged.wordpress.com/2010/01/21/open-source-development-not-very-open-or-welcoming/.

Have a pleasant morning/day/evening/night.

Providing an option to display the native title bar is a specific integration option.

You're crop the "for DE" part

You just said a couple of replies above that even if there are a lot of complaints PRs are still refused.

Yeah, most options are added after a lot complains, but some requests are no-go even after that. #90 and #2060 are good examples for that.

Just remembered about #3830, seems to be the right original ticket

Hi, Telegram quits completely on hitting Alt+F4 or Ctrl+Q. Till a certain update (my bad I don't remember the version) when clicking X button or pressing Clrl + W it slips into background (as it's supposed to do). But now, I'm testing beta and I see that feature is gone!

While switching windows (Alt+Tab) or in a multitask view if telegram is running in the background it won't show up, which helps a lot to minimize clutter. I'd like to see that feature back.

This wasn't a feature, there was a race condition in tray detection so that for some users the app wasn't closed. You're kind of slowpoke if the fix is landed to you only now. You can see that quit-without-tray code is present from the first repository commit.

Was this page helpful?
0 / 5 - 0 ratings