Telegram replaces the launcher desktop file with a weirly named one on linux

[mrmeszaros]

Steps to reproduce

1. Create a desktop file manually, e.g.: ~/.local/share/applications/telegramdesktop.desktop

[Desktop Entry]
Version=1.0
Name=Telegram Desktop
Comment=Official desktop application for the Telegram messaging service
TryExec=/home/vagrant/.local/share/TelegramDesktop/Telegram
Exec=/home/vagrant/.local/share/TelegramDesktop/Telegram -- %u
Icon=telegram
Terminal=false
StartupWMClass=TelegramDesktop
Type=Application
Categories=Network;InstantMessaging;Qt;
MimeType=x-scheme-handler/tg;
Keywords=tg;chat;im;messaging;messenger;sms;tdesktop;
X-GNOME-UsesNotifications=true

2. Install Telegram
3. Launch Telegram
4. Inspect the ~/.local/share/applications folder for the desktop launcher file (replaced)

Expected behaviour

Telegram should not replace the launcher file.

If if must, then it should use a name that does not contain a 32 character hexa identifier.

Actual behaviour

After the first launch, telegramdesktop.desktop gets replaced with org.telegram.desktop._<32LONG_HEX>.desktop.

It even says it in the ~/.local/share/TelegramDesktop/log.txt

If I rename the desktop file to something, then the dock icon for the application breaks.

Operating system

Ubuntu 22.04, GNOME

Version of Telegram Desktop

4.5.3

Installation source

Static binary from official website

Logs

...
[2023.01.11 15:02:27] Executable path before check: /home/vagrant/.local/share/TelegramDesktop/Telegram
[2023.01.11 15:02:27] Logs started
[2023.01.11 15:02:27] Launcher filename: org.telegram.desktop._102e2be7fdb48dfc5164611f2f7fd6af.desktop
[2023.01.11 15:02:27] Connecting local socket to /tmp/9b4389f2b23f460fe40f59f288370d39-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.01.11 15:02:27] This is the only instance of Telegram, starting server and app...

[ilya-fedin]

If if must, then it should use a name that does not contain a 32 character hexa identifier.

What's the problem with having hex identifier? User may have multiple Telegram binaries in the system in different directories with different profile directories, so it's a must to have identifier to avoid replacing each other's launcher.

If I rename the desktop file to something, then the dock icon for the application breaks.

Yeah, you shouldn't choose the name on your own, .desktop file is important for various system APIs to work, so you should follow the name upstream chooses.

[ilya-fedin]

Removing telegramdesktop.desktop is also not a bug, but intended behavior, to avoid having multiple .desktop files when updating from old version.

[mrmeszaros]

First of all, thanks for the quick reply and the explanation.

By the way - how does having multiple installations that work?
I assume I would have multiple org.telegram.desktop._<ID>.desktop files - but how would I differentiate from the GUI?
Because the neither the Name nor the Comment directive does not contain anything related to the ID.

I know this would mean a refactor, but one could use the Exec directive with an env variable, to pass an ID value, like

Exec=env TD_ID=value /home/vagrant/.local/share/TelegramDesktop/Telegram -- %u

It's just an idea that popped into my mind - as usually application configuration resides in ~/.config/APP_NAME.

Anyway, to give some background info, I am installing Telegram automatically, hence I need a filename that is consistent.
Is there a way to generate the desktop entry from the Telegram binary?
Something like: Telegram --generate-desktop-file that creates the file and hopefully prints the generated file path to the stdout.

Also, the replaced desktop entry has an extra Quit Action, that is unnecessary on GNOME, but that is just a minor nuisance.

[ilya-fedin]

By the way - how does having multiple installations that work?

You need to create TelegramForcePortable folder near the binary

I know this would mean a refactor, but one could use the Exec directive with an env variable, to pass an ID value, like

I don't think that's a good idea. The ID is automatically generated from the path to the binary or from the path to the profile directory (if it's overriden with -workdir). Allowing to supply custom IDs may lead to conflicts...

Anyway, to give some background info, I am installing Telegram automatically, hence I need a filename that is consistent.

How is that connected? 🤔 Just let tdesktop create it automatically.

Also, the replaced desktop entry has an extra Quit Action, that is unnecessary on GNOME, but that is just a minor nuisance.

But it was requested exactly by GNOME users...

[mrmeszaros]

Thanks for all the answers.
The GNOME one baffled me - but GNOME changed over the years - maybe it was useful once and now GNOME provides a Quit action out-of-the-box for each application. Anyway, that was just a side-thing, I do not mind it.

How is that connected? 🤔

I am using ansible to provision the system - it has idempotent tasks: I can say the file telegram-desktop.desktop should be present, and the system only runs some script if changes are required.
I would like to have the Telegram desktop file installed by ansible.

Just let tdesktop create it automatically.

Are you saying that I can run Telegram from shell (no GUI) for some amount of time, and it will create the desktop file?

You need to create TelegramForcePortable folder near the binary

Wouldn't then it be logical to only generate the unique IDs if its a portable install?

BTW, I understand that the desktop file needs to be linked to the installation via some way, but having multiple portable installations results in multiple org.telegram.desktop._ID.desktop files, that have the same Name and Icon attribute meaning they would look identical from the application menu.

Also, why would someone want multiple Telegram binaries in one system user account? You can have multiple accounts inside of telegram, and as I said, the name and icon in the app menu would be the same for all: org.telegram.desktop._ID1.desktop, org.telegram.desktop._ID2.desktop etc.

Also, thanks again for taking Your time to elaborate!

[ilya-fedin]

Wouldn't then it be logical to only generate the unique IDs if its a portable install?

We don't want to conflict with system package manager installations...

Also, why would someone want multiple Telegram binaries in one system user account?

idk, but people are actively using this...

Are you saying that I can run Telegram from shell (no GUI) for some amount of time, and it will create the desktop file?

No, it's installed on first launch and updates... Although maybe it's a good idea to overwrite it on every launch.

I am using ansible to provision the system - it has idempotent tasks: I can say the file telegram-desktop.desktop should be present, and the system only runs some script if changes are required.

Maybe it's better to install tdesktop in system directory and use the /etc/tdesktop/externalupdater config (you need to specify path to the binary in the config)?

[ilya-fedin]

The GNOME one baffled me - but GNOME changed over the years - maybe it was useful once and now GNOME provides a Quit action out-of-the-box for each application. Anyway, that was just a side-thing, I do not mind it.

Are you sure it does the same thing? Maybe it just closes the window rather than really quitting Telegram?

[ilya-fedin]

Because I'm doubt how GNOME can know how it can gracefully quit tdesktop...

[mrmeszaros]

Okay, I am fine with the Quit action.

I am also okay with Telegram ensuring its desktop file works correctly at every launch.

One last thing - would it be possible to add the option to generate the desktop file and print the filename (without instantiating the GUI)?
Or an option to disable the unique ID generation and use a fixed default / or maybe even a user provided with like --installation-id ID? (The option naming is just a proposal, could be anything.)

Since Telegram automatically manipulates the desktop file, it would give some power back to me, the sysadmin.
Additionally, it would be really nice to have a --help page that describes all options.

I can open a separate issue if that helps, since this issue started differently.

[ilya-fedin]

There are no arguments meant to be used by end users, hence there's no --help. And personally I don't want to add ones and all the corresponding headache (like maintaining a --help option).

[ilya-fedin]

Since Telegram automatically manipulates the desktop file, it would give some power back to me, the sysadmin.

What's the problem with externalupdater config described earlier?

[mrmeszaros]

There are only two files in a downloaded tsetup.4.5.3.tar.xz:
Telegram/Telegram and Telegram/Updater.

I assume by /etc/tdesktop/externalupdater You refer to the Updater.
I cannot run through an SSH session (no GUI):

vagrant@ubuntu2204 ~/.local/share/TelegramDesktop> ./Updater
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, wayland, wayland-egl.

so sadly that does not solve my problem.

There are no arguments meant to be used by end users, hence there's no --help. And personally I don't want to add ones and all the corresponding headache (like maintaining a --help option).

Understandable, documentation and keeping it in sync can be a headache. However, I see there are a solid few options that I didn't even know existed.

tdesktop/Telegram/SourceFiles/core/launcher.cpp

Lines 491 to 506 in 5910efa

	auto parseMap = std::map<QByteArray, KeyFormat> {
	{ "-debug" , KeyFormat::NoValues },
	{ "-freetype" , KeyFormat::NoValues },
	{ "-key" , KeyFormat::OneValue },
	{ "-autostart" , KeyFormat::NoValues },
	{ "-fixprevious" , KeyFormat::NoValues },
	{ "-cleanup" , KeyFormat::NoValues },
	{ "-noupdate" , KeyFormat::NoValues },
	{ "-tosettings" , KeyFormat::NoValues },
	{ "-startintray" , KeyFormat::NoValues },
	{ "-quit" , KeyFormat::NoValues },
	{ "-sendpath" , KeyFormat::AllLeftValues },
	{ "-workdir" , KeyFormat::OneValue },
	{ "--" , KeyFormat::OneValue },
	{ "-scale" , KeyFormat::OneValue },
	};

And it would be really nice to know what these do (some are pretty self-explanatory, like -quit or -workdir).
Like -fixprevious sets LaunchModeFixPrevious and that in turn makes exec() call psFixPrevious():

tdesktop/Telegram/SourceFiles/core/launcher.cpp

Lines 336 to 337 in 5910efa

	if (cLaunchMode() == LaunchModeFixPrevious) {
	return psFixPrevious();

but I lost trace at that point to figure out what it does or does it help me.

But according to this, it seems to me that it could be possible to add one more LaunchMode, like -generatedesktop.

[ilya-fedin]

I assume by /etc/tdesktop/externalupdater You refer to the Updater.

No, I say you should create config named externalupdater in /etc/tdesktop with the path to the Telegram binary as the content.

However, I see there are a solid few options that I didn't even know existed.

All those options are either for service purpose (the code creates shortcuts with them, Windows installer uses them, the binary itself restarts with them, etc) or for developers. None of them meant to be used by end users.

[ilya-fedin]

But according to this, it seems to me that it could be possible to add one more LaunchMode, like -generatedesktop.

It's possible, I think it's just shouldn't be done. Or then sysadmins will go here and ask for a lot of modes, with a little different purpose while there's already externalupdater config.