Handlr fails to open some file types

[TiZ-HugLife]

Hiya, sorry to bother you again, but I'd love to see this utility flourish. It seems that handlr doesn't know about some associations, and I'm not sure why.

I tested it out like so:

Aura Another Star OST $ handlr open 27\ -\ Necru\ Feratu.mp3
Error: NotFound
Aura Another Star OST $ handlr list
┌───────────────────────────────────────┬──────────────────────────────────────┐
│ application/vnd.bg-rcs-northernkentu+ │ handler-application-vnd.bg_rcs_nort+ │
│ application/x-ruby                    │ org.geany.Geany.desktop              │
│ application/x-shellscript             │ org.geany.Geany.desktop              │
│ application/xml                       │ org.geany.Geany.desktop              │
│ image/png                             │ mirage.desktop                       │
│ text/plain                            │ org.geany.Geany.desktop              │
│ text/x-crystal                        │ org.geany.Geany.desktop              │
│ text/x-lua                            │ org.geany.Geany.desktop              │
└───────────────────────────────────────┴──────────────────────────────────────┘

Is it normal for list's output to be so abbreviated?

I'm inclined to say it only knows about custom associations, but then I'm confused as to why it succeeds in opening https URIs. Another thing is that the application installed for opening .mp3 files is Celluloid, installed via Flatpak. I have LibreOffice as a Flatpak and it can't open .odt files. But again, that makes me wonder why it succeeds in opening https URIs. My archiver is installed as a system package, but it can't open tarballs either.

What do you need from me to help you diagnose this? :)

[chmln]

This can happen if no .desktop files have audio/mp3 in their MimeType and no default association is added in your mimeapps.list.

For instance, I have feh.desktop in /usr/share/applications:

$ cat /usr/share/applications/feh.desktop 
[Desktop Entry]
Name=Feh
...
MimeType=image/bmp;image/gif;image/jpeg;image/jpg;image/pjpeg;image/png;image/tiff;image/webp;image/x-bmp;image/x-pcx;image/x-png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-tga;image/x-xbitmap;

What distro/DE are you using? Can you cat the content of the celluloid .desktop file? It's usually in /usr/share/applications or ~/.local/share/applications.

P.S. appreciate you opening issues, good issues like this are in fact helpful rather than bothersome.

[chmln]

The .desktop file must be the culprit, maybe flatpak is using a modified version or something.

The .desktop from celluloid repo looks good. I confirmed this by installing it myself from arch repos and the associations were recognized by handlr properly.

[TiZ-HugLife]

I'm on XFCE 4.12 under Xubuntu 18.04. Looking to update to 20.04 soon.

Are you checking the value of the XDG_DATA_DIRS environment variable? This variable is required for Flatpak applications to be found by the desktop environment and other applications that open things. It's a colon-separated list of directories to check for data. None of Flatpak's .desktop files exist in /usr/share/applications or ~/.local/share/applications. They're in $flatpak_installation/exports/share/applications.

In addition, there's no guarantee that XDG_DATA_HOME is ~/.local/share, and that should be checked as well.

[chmln]

That's it, XDG_DATA_DIRS is the cause. Expect a fix out soon

[chmln]

Hey @TiZ-EX1, let me know if v0.3 fixed your issue :)

[TiZ-HugLife]

Hey there. Definitely closer. But it seems to not quite be on the same page as Thunar for what application should open what files.

Aura Another Star OST $ handlr list
┌───────────────────────────────────────┬──────────────────────────────────────┐
│ application/vnd.bg-rcs-northernkentu+ │ handler-application-vnd.bg_rcs_nort+ │
│ application/x-ruby                    │ org.geany.Geany.desktop              │
│ application/x-shellscript             │ org.geany.Geany.desktop              │
│ application/xml                       │ org.geany.Geany.desktop              │
│ audio/mpeg                            │ io.github.celluloid_player.Celluloi+ │
│ image/jpeg                            │ org.gnome.eog.desktop                │
│ text/plain                            │ org.geany.Geany.desktop              │
│ text/x-crystal                        │ org.geany.Geany.desktop              │
│ text/x-lua                            │ org.geany.Geany.desktop              │
│ video/x-matroska                      │ io.github.celluloid_player.Celluloi+ │
└───────────────────────────────────────┴──────────────────────────────────────┘
Aura Another Star OST $ handlr open 27\ -\ Necru\ Feratu.mp3 
Aura Another Star OST $ error: app/io.github.quodlibet.QuodLibet/x86_64/stable not installed

The reason for this error is actually my bad; I had a custom .desktop file for Quod Libet when I was still using it... but I'm not anymore, I'm using Spotify. So I got rid of the file but it's still trying to open Quod Libet for some reason? Regardless, when I double click the file in Thunar, Celluloid opens, and right-click doesn't even show Quod Libet as an option.

It does successfully open LibreOffice though, so progress has definitely been made! :D

[chmln]

@TiZ-EX1 it must mention quod libet when you run handlr get .mp3, can you post the content of that file and also spotify.desktop? That'd help clarify things.

Because if both quod libet and spotify supports mp3 files, we run into an ambiguous situation and probably just pick the first handler encountered.

[TiZ-HugLife]

Here's the problem:

Aura ~ $ handlr get .mp3
io.github.quodlibet.QuodLibet.desktop.off

I guess "got rid of the file" is still technically true for this. I had a custom .desktop file and renamed it. Nothing else pays attention to this file. It shouldn't be paying attention to files that don't end in .desktop.

Quod Libet opens MP3s, Spotify doesn't. Celluloid does. I'm a little concerned about reinventing the wheel over and over TBH, because the more you do that, the more risk you run of doing things differently than the file manager or the rest of the desktop environment, which will result in bug reports and general complaints. So WRT ambiguous situations... IMO that should be solved however xdg-utils does it.

[chmln]

Thanks for feedback @TiZ-EX1

I'll filter out non-desktop files

[TiZ-HugLife]

I'm gonna go ahead and close this because handlr thus far has been behaving correctly. I'll open a new one if I find more wonkiness and narrow down something specific. We did fix a specific issue here so I think it's a fair thing to do. Thanks for your work on this!

[chmln]

@HugLifeTiZ Thanks a lot for your feedback :) Yes, feel free to open up an issue for any bugs or suggestions