Malformed entry in desktop file

[chmln]

Malformed entry in desktop file

[chmln]

@Kabouik please try v0.4.4 and let me know if the issue is fixed! :)

[Kabouik]

It's working, thanks a lot!

[Kabouik]

There's another issue though, I'm not sure if it is related to that one but since I did not notice it before, maybe you'll know better:

I noticed that you updated the README to explain how to add extra handlers, so I wanted to test. I configured handlr.toml to my liking to use my rofi theme, set enable_selector = true, and then ran handlr add .mp3 sayonara.desktop. When I click on a .mp3, cmus is still being used by default and rofi doesn't show up. Yet, the .toml file is correct because if I handlr get .mp3, then rofi selector appears.

Another thing: if I handlr open /path/to/mp3, it opens Audacity. I have no idea where this comes from, since Audacity is not listed in handlr list. I guess it might be some leftovers in other mime/whatever files?

[chmln]

@Kabouik it is probably because handlr open detects an mp3 file as audio/mpeg, while .mp3 gets resolved as audio/mp3.

I've fixed this in v0.4.5 by resolving the extensions through the same database that's used to guess the mime from content.

Thanks for providing useful feedback!

[Kabouik]

Thanks for the quick fix! Just after updating handlr, I ran handlr get .mp3 and this time it returned audacity.desktop indeed. I now set again cmus.desktop as default and sayonara.desktop as extra.

Not sure if this is a real issue or if it's caused by my hacky desktop file:

• Double click on an mp3 file in a file manager → adds mp3 to queue in cmus. No rofi selector despite the option being enabled. cmus is my default so I'm no particularly surprised, but I was assuming the selector would show up in this situation.
• handlr open /path\ with\ spaces/to/file.mp3 → rofi selector. Select Sayonara and see the program open up with the file in its play queue; else select cmus and see the file failing to add in the play queue, because of the spaces in the path (confirmed working without spaces). Perhaps it's an issue in my .desktop's Exec= but if so, I would expect it to fail similarly when double clicking in a file manager.

[chmln]

@Kabouik it depends on how the file manager handles double-clicking. There's a few options

1. it uses something specific like gvfs-open or similar, which does not call handlr
2. it uses xdg-open. In this case you can install https://aur.archlinux.org/packages/xdg-utils-handlr or override it manually

If you want you can let me know what DE/file manager you use and I could look into it

[Kabouik]

Thanks. Since I don't use Arch, I just created two aliases in my ~/bashrc instead of creating a bash file in /usr/bin:

alias xdg-open='handlr open "$@"'
alias gvfs-open='handlr open "$@"'

And then confirmed from command line that both aliases now call handlr (.mp3 files invoked the rofi selector).

The issue with files containing a space in their path was due to missing quotes in my cmus.desktop's Exec line. Not sure why it was working correctly from file managers and not from command line, but anyway I fixed it with:

Exec=bash -c '(! pgrep cmus && tilix -e cmus && tilix -a session-add-down -e cava); sleep 0.1 && cmus-remote -q "%f"'

Nautilus still bypasses handlr though, I have to investigate and see what it is using by default and maybe make another alias. nnn does the same, although it should be using xdg-open, there must still be something I'm missing.

[Kabouik]

Turns out trying to be smart and making aliases instead of using a script placed in $PATH was a very bad idea, since aliases work only directly in a shell, not when called from other programs (this is what I learnt here). Works as expected with the simple script you linked in my user $PATH to replace xdg-open from the base $PATH.