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? :thinking: 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? :thinking:

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. https://github.com/telegramdesktop/tdesktop/blob/5910efa0bdd3cf4ed1a1f73406c82c1db552a50b/Telegram/SourceFiles/core/launcher.cpp#L491-L506 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(): https://github.com/telegramdesktop/tdesktop/blob/5910efa0bdd3cf4ed1a1f73406c82c1db552a50b/Telegram/SourceFiles/core/launcher.cpp#L336-L337 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.

[mrmeszaros]

Hey, I tried using the externalupdater, but it resulted in an even bigger mess. After creating /etc/tdesktop/externalupdater containing the path to the Telegram binary, I ran ~/.local/share/TelegramDesktop/Telegram from the console, and it generated a more botched up desktop file:

~> cat .local/share/applications/userapp-Telegram\ Desktop-5BGWZ1.desktop
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/home/vagrant/.local/share/TelegramDesktop/Telegram -- %u
Name=Telegram Desktop
Comment=Custom definition for Telegram Desktop

It has NoDisplay=true so, I also tried creating a proper desktop file and start from there on a fresh install, and it seems to be working. The userapp-... file still generates, but it at least does not touch my desktop file. so thank You!

I cannot say I am happy with telegram desktop deviating from the vast majority of other desktop apps in its workings, but on the other hand, I am glad it exists, and that it works.

[ilya-fedin]

It's a file for URL scheme handler. You should provide the launcher on your own, with the name org.telegram.desktop.desktop

[ilya-fedin]

I cannot say I am happy with telegram desktop deviating from the vast majority of other desktop apps in its workings

What do you mean by this? The vast majority of desktop apps on Linux don't provide pre-compiled builds at all. If you compare with apps installed from package manager then you probably should compare with tdesktop from package manager as well.

[mrmeszaros]

Fristly

Thanks - with org.telegram.desktop.desktop it works like a charm!

Secondly

The vast majority of desktop apps on Linux don't provide pre-compiled builds at all.

I thought that the userapp-Telegram\ Desktop-5BGWZ1.desktop will still be generated with the externalupdater, and while not happy, it wasn't looking like a big fuss.

You are right though - most desktop apps are available through the package manager, and thus mostly not up to date. From the homepage download I assumed that Telegram is available through Flatpak, Snap (I do not use neither of these, and am not fond of mixing package management systems) and the portable install method we are currently discussing.

Since then, I looked into it deeper, and found that a pretty old version (3.6.1) is available in the official Ubuntu jammy/universe apt repository and also some not so old version (4.2.4) from the unofficial atareao private package archive (ppa: https://launchpad.net/~atareao/+archive/ubuntu/telegram).

Thanks for pointing out my mistake abouf the comparison.

Thirdly

I do not really like an user-specific configuration living under /etc. For me it would be more logical if a portable install's config lived inside the user's home folder, like ~/.config/tdesktop/externalupdater or maybe ~/.local/share/TelegramDesktop/externalupdater.

On the other hand, as this externalupdater signals to telegram that it is a singleton install (if I understand correctly) - then it would make sense to install it under a system directory like /opt/tdesktop, and make it writable by any user (so that telegram is able to update itself whoever runs it). But it is quite muddy to me how telegram does this, and what are the options (maybe have the install location owned by a tdesktop usergroup, and add the users to it?).

Anyway, I understand that this might fall under the category You already pointed out (if You add this, then others might want their stuff added too), but I felt I needed to give voice to my concern.

And last but not least, I want to say I am grateful for Your time and effort.

[ilya-fedin]

I do not really like an user-specific configuration living under /etc.

That config is for system-wide installation. It's not considered that someone would like to manage installations with an external tool user-wide.

On the other hand, as this externalupdater signals to telegram that it is a singleton install (if I understand correctly)

I'm not sure what do you mean by 'singleton', you can specify multiple paths, line-by-line.

and make it writable by any user (so that telegram is able to update itself whoever runs it)

The externalupdater means auto-updates won't happen. You manage the updates for the user.

[ilya-fedin]

You likely can invent some updater with bash scripts, GitHub API and launch it with cron/systemd timer. Or you can use flatpak/snap package.

[mrmeszaros]

That config is for system-wide installation.

That is what I wanted to say - a single system-wide install. But I understand that there can be multiple system-wide installations.

you can specify multiple paths, line-by-line.

So it is a list of Telegram binaries that should not use auto-update?

You likely can invent some updater with bash scripts, GitHub API and launch it with cron/systemd timer.

In the tar.gz a binary named Updater comes with the Telegram binary. Can that be used? What is it for? Is the previously talked about UUID otherwise required by the auto-updater?

[ilya-fedin]

So it is a list of Telegram binaries that should not use auto-update?

It's a list of binaries that should behave as installed by external tool even though not recompiled with the respective build option.

In the tar.gz a binary named Updater comes with the Telegram binary. Can that be used? What is it for?

It replaces the binary file previously downloaded by Telegram itself into data directory.

Is the previously talked about UUID otherwise required by the auto-updater?

UUID?

[mrmeszaros]

Cool! Now I understand the purpose of externalupdater.

UUID?

I created the whole issue because the desktop file got replaced with org.telegram.desktop._<32_LONG_HEX_UUID>.desktop. So just to understand it better - is the UUID needed because of the auto-updater? (since using an external ensured that the desktop-file did NOT get replaced - so no UUID was generated I guess).

You likely can invent some updater with bash scripts, GitHub API and launch it with cron/systemd timer.

I am considering this - I understand there is no option (like -version) on the binary to determine the currently installed binary version, right?

[ilya-fedin]

So just to understand it better - is the UUID needed because of the auto-updater?

No, it's a md5 hash from the path to the binary or to the data directory (depending on whether -workdir argument is used). Desktop file installation depends on auto-updater. As desktop file is assumed to be installed externally in this case, the hash is not used.

I am considering this - I understand there is no option (like -version) on the binary to determine the currently installed binary version, right?

No.

[mrmeszaros]

Okay, thanks for the answers - one last question:

If I (manually) update the Telegram binary while it is running - currently I need to restart Telegram. Is there a way to "hot-swap" it - like the auto-updater is doing?

[ilya-fedin]

just remove it and copy/move the new one?

[mrmeszaros]

I did that - downloaded the new binary and replaced (overwritten) the old with the new. Still, I need to manually restart Telegram in to use the new one - and AFAIK using the the auto-updater there is no need for this. This is what I meant by hot-swap.

[ilya-fedin]

I'm not aware of any standards for package managers to signal applications to restart themselves, so I have no idea how to implement that.

[ilya-bystrov]

This thread seems relevant to my question.

Why does Telegram need to update a desktop file every time before quit? I don't like this idea. I think it's OK to update a desktop file after a binary update. Then I expect that I can manage my desktop files on my own. It means that I can change Name, Icon, Exec to launch a wrapper script or somehow adapt app to my environment.

For instance, I prefer to have 'Telegram' instead of 'Telegram Desktop' name. But my changes are reset after quitting the app.

Moreover, Telegram creates a new desktop file if the previous file is not allowed to be modified: $HOME/.local/share/applications/org.telegram.desktop._010ee3bf1fc5292f9a771f34f8d00776.desktop $HOME/.local/share/applications/org.telegram.desktop._a5eb629b9118148fc40161ee8686d1fa.desktop

The acceptable alternative would be turning off a desktop file creation completely. Is it possible? Probably, this TelegramForcePortable mode allows me to get this behavior?

[ilya-fedin]

Why does Telegram need to update a desktop file every time before quit?

There were like 5 times people complained they don't have the launcher after deleting it last month.

[ilya-fedin]

@Aokromes I believe it's the time to close the issue

[eugene-yang]

Well... keep updating the launcher file seems to be a hotfix for the problem of launcher file disappearing.... I use the environment variable to pass in QT module variables. So this became quite annoying to me. It basically prevents me from configuring how exactly I want my application to be run. If there's a way to turn that off, I would appreciate that.

[ilya-fedin]

It's a bad practice to apply such variables not session-wide

[ilya-bystrov]

@eugene-yang Yeah, for me, this behavior sounds like a dirty hack.

(1) In general, desktop files are allowed to be created/modified by end users. There are even programs that provide this functionality: low-level desktop-file-install, alacarte, menulibre.

(2) There are a lot of desktop environments. Some of them can have their own desktop entry keys (for instance, KDE). Current behavior prevents any such modifications (they will be wiped out on the next run).