open: Tries to open, not launch, desktop files and shows duplicates

[louies0623]

[probonopd]

It seems like you are trying to open a application/x-desktop file. Those should in fact be launched, not opened.

https://t.me/setlanguage/zh-hant-beta in Chrome asks whether to open this with xdg-open. Since we are not using xdg-open but our replacement open command, it gets passed to there. On my system, it asks to choose an application to open x-scheme-handler/tg MIME types. On my system, it doesn't find any. On your system, it appears to pick up a desktop file for an AppImage that can handle this scheme, but then tries to open rather than to launch that desktop file.

Probably we need to add checks to ensure that desktop files are always launched, even when they are passed to open.

[probonopd]

Additionally, we need to filter the list so that every entry is shown only once.

[probonopd]

Thanks @louies0623, please check if 0H352 and later improve this.

[louies0623]

Is it update from the update utilities?

[probonopd]

No. The new version is at https://github.com/helloSystem/launch/releases and will be in helloSystem ISO 0H352 and later.

[louies0623]

It’s fixed, but libreoffice, transmission and Iridium are not installed, why are they still on it?

[probonopd]

Probably the system doesnt find an application that can handle x-scheme-handler/tg and hence shows all applications that can handle any x-scheme-handler/*.

% find ~/.local/share/launch/MIME/x-scheme-handler_tg/ -not -type d
find: ~.local/share/launch/MIME/x-scheme-handler_tg/: No such file or directory

It this is the case, then it will show any

find ~/.local/share/launch/MIME/x-scheme-handler_*/ -not -type d

We probably will need some logic to put Telegram in there.
Is your system aware of it at all?

% find ~/.local/share/launch/Applications -not -type d | grep -i telegram

On my system it finds nothing because I don't have Telegram.

After downloading it from https://github.com/srevinsaju/Telegram-AppImage/releases and opening it in the Filer, now it shows:

% find ~/.local/share/launch/Applications -not -type d | grep -i telegram
~/.local/share/launch/Applications/Telegram_Desktop-x86_64.AppImage

If it finds something on your system, you could try:

mkdir -p ~/.local/share/launch/MIME/x-scheme-handler_tg/
ln -sf <path to what you found above> ~/.local/share/launch/MIME/x-scheme-handler_tg/

In my example:

% ln -sf ~/.local/share/launch/Applications/Telegram_Desktop-x86_64.AppImage ~/.local/share/launch/MIME/x-scheme-handler_tg/

As a result, https://t.me/setlanguage/zh-hant-beta indeed gets opened with Telegram.

Do you start to like the logic of our filesystem-based launch "database"?

---

So it seems that what is missing for this to be automatic is that a link to the AppImage needs to get placed into ~/.local/share/launch/MIME/x-scheme-handler_tg/ automatically.

[probonopd]

% chmod +x ~/Downloads/Telegram_Desktop-x86_64.AppImage 
% ~/Downloads/Telegram_Desktop-x86_64.AppImage --appimage-extract
% cat squashfs-root/telegram.desktop
(...)
MimeType=x-scheme-handler/tg;
(...)

So, when encountering an AppImage, then "the system" (I still need to decide which component) needs to place the link to ~/.local/share/launch/MIME/.../ based on the information in MimeType= in the .desktop file inside the AppImage. (This already happens for .desktop files which are not inside AppImages.)

[probonopd]

Note on privacy In order to use Signal or Telegram, you need a phone number. This number is shared with anyone you talk to while using these platforms, and can even be used to find you. This could be a problem if you're someone who doesn't want your conversations linked to your real-world phone number.

For this reason, I am not supporting these services. Until they provide a way to use them without a phone number.

[louies0623]

Most people use these software for work and to connect with family and friends, it is not easy to change, if the user does not need a phone to log in, then Kopete, FluffyChat, Caprine or Pidgin is an option.

[probonopd]

Closing this as the original issue is solved.

The remaining issue will be discussed at

• Read desktop files inside AppImages #27