Every time net-im/telegram-desktop-bin is being updated (Telegram version is being increased), in generates file ~/.local/share/applications/telegramdesktop.desktop This behavior is caused by this code: https://github.com/telegramdesktop/tdesktop/blob/master/Telegram/SourceFiles/platform/linux/specific_linux.cpp TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION is undefined by default, and Telegram upstream developers doesn't want to modify this behavior in upstream. However, each time net-im/telegram-desktop-bin is being emerged, it creates file /usr/share/applications/telegramdesktop.desktop So we have two Telegram .desktop files on Linux after update. It causes the following issue: in awesome WM desktop menu or in GNOME/KDE menu we have two Telegram apps instead of one. Possible solution: net-im/telegram-desktop-bin ebuild should remove /usr/share/applications/telegramdesktop.desktop in src_install() phase.
Good point. I am mainly using plasma and there the .local one seems to win over the one from the package. The KDE menu contains just one entry. The fact that the package brings its own updater and provides such files is a major issue. I am still hoping we can eventually just compile that without the custom qt. I just had a quick look at https://specifications.freedesktop.org to figure out what is supposed to happen when having two .desktop-files with the same name. My first wild guess is that there is some kind of preference here and only one entry should end up in the menu (see $PATH). But i could not confirm that without truly reading the spec. On KDE/Plasma it would probably be ok to not ship a .desktop with the package, but i am not convinced that would work for any GUI-shell. Will the application always create that file when it is started? But even if, we would not have a .desktop entry for the first launch.
> Will the application always create that file when it is started? ~/.local/share/applications/telegramdesktop.desktop is being created in two cases: 1. When we launch Telegram for current user for a first time (i.e. this user has no Telegram configs in $HOME at all). In this case, ~/.local/share/applications/telegramdesktop.desktop is created. 2. When we updated Telegram via portage (e.g., from 1.2.1 to 1.2.2) and relaunched it. When Telegram detects that his version is increased, it recreates ~/.local/share/applications/telegramdesktop.desktop.
Related comment of the main Telegram upstream developer: https://github.com/telegramdesktop/tdesktop/pull/2181#issuecomment-227749814 TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION is undefined by default in the source code by that developer. Reason: > The main code branch is used to build a version that is distributed > through https://desktop.telegram.org/ in a simple compressed way and > it should work just by download-unpack (like it does right now). > This is the only version that is currently officially offered by > Telegram, anyone else can build their own versions with or > without .desktop file generation and distribute through any package > manager they prefer. So in my opinion, there are two ways to fix it: 1. Remove /usr/share/applications/telegramdesktop.desktop in ebuild. This file should not be installed. 2. Maybe provide net-im/telegram-desktop-not-bin with #define TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION defined. The first way is more simple.
The same issue on Ubuntu Linux: https://github.com/telegramdesktop/tdesktop/issues/1127 > I found that there was an extra telegram.desktop placed > in ~/.local/share/applications. I removed the file and the > duplicate icon is gone.
(In reply to Viktor Levin from comment #3) > Related comment of the main Telegram upstream developer: > > https://github.com/telegramdesktop/tdesktop/pull/2181#issuecomment-227749814 > > TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION is undefined by default in the > source code by that developer. Reason: > > > The main code branch is used to build a version that is distributed > > through https://desktop.telegram.org/ in a simple compressed way and > > it should work just by download-unpack (like it does right now). > > This is the only version that is currently officially offered by > > Telegram, anyone else can build their own versions with or > > without .desktop file generation and distribute through any package > > manager they prefer. > > So in my opinion, there are two ways to fix it: > > 1. Remove /usr/share/applications/telegramdesktop.desktop in ebuild. This > file should not be installed. In this case there is no .desktop for the initial run, so uses would not find telegram in their launcher menu after installing it. And the .local one would potentially only be visible after that menu cache was rebuild, which telegram might not do. > 2. Maybe provide net-im/telegram-desktop-not-bin with #define > TDESKTOP_DISABLE_DESKTOP_FILE_GENERATION defined. Such a version would be the way to go, but last time i looked into building it from source it pulled in a custom qt and turned out to be very hard. The fact that it updates itself is an even bigger issue that comes with the -bin. > The first way is more simple.
I am tempted to give that bug a wontfix. Are we clear about the .desktop file parsing order and whether two menu-entries are not just a bug in awesome WM. You claimed that KDE is also affected, but i can not confirm that.
I commented on https://github.com/telegramdesktop/tdesktop/pull/2181 and suggested a way to deal with that problem. Not sure if they will react on that. Another way would be to open an issue, but they have so many of them i did not want to create a duplicate. For now i would suggest to wait and see if an issue would have been the better idea.
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.2.html#desktop-file-id If both have the same relative path, only one should be used.
Guys, Arch Linux wiki says that it is awesome WM menu issue: https://wiki.archlinux.org/index.php/awesome#Duplicate_menu-entries_generated_by_Xdg-menu > Xdg-menu will generate duplicate entries if you copy desktop-files from /usr/share/applications to ~/.local/share/applications even though it might be preferable to simply override the originals
This is not Telegram issue: https://github.com/awesomeWM/awesome/issues/1816
I've just re-checked in recent KDE - no bugs found. So it is awesome WM specific bug.
Ok. Viktor i guess we can close this bug now. Maybe the comment in upstream telegram will result in upstream improvements. Please give me the OK to close this one, or do so yourself.
Nah, let's just update it to point where the bug lies.
Well, we'll have to wait for upstream action on this. Hopefully next release will have this fixed.
