Add an "enqueue" action to the context menus

[dark-penguin]

Add an "Enqueue" action to the context menus of files and also directories on Linux.

[dark-penguin]

Not tested yet as I can't figure out how to build the project

[Oleksiy-Yakovenko]

In theory, you can test this just by adding such desktop file to an existing install, since this doesn't change any code that requires building.

[dark-penguin]

I'm not entirely sure that this will add this new file properly - I've added it to the makefile, but I don't know if that's enough. Then I've noticed that the build process is not so straightforward anyway, so I should work on that as well anyway.

[dark-penguin]

Oh, another note: not even my Chinese-speaking friend was able to figure out what's the Chinese for "Enqueue". In qmmp, it's written like this:
Name[zh_CN]=加入 Qmmp 播放列表
Name[zh_TW]=加入 Qmmp 播放清單
I've left it untouched for now - the same as "Play", which is definitely not going to be a good experience for the Chinese users - two items that read the same...

[dark-penguin]

Maybe we can just change "Qmmp" to "DeaDBeeF" here, and hope that whatever this says is not very far from the usual "Enqueue" message...

[Oleksiy-Yakovenko]

Google translate says it's "Add to Qmmp playlist"

[dark-penguin]

Today I was trying various music players for Linux, to finally choose one and use something other than smplayer. DeaDBeeF was an immediate clear winner - unlike every other one, DeaDBeeF has no bugs that I immediately noticed, it has all its functions function properly, and it has a lot of useful capabilities. Thank you for this project!

The only two things I could wish for is this, which I could figure out myself, and being able to bulk-remove MP3 tags from multiple files in one click, like foobar2000 did. But it's probably possible with two or three clicks - I'll try that later.

[dark-penguin]

I gave up trying to run the existing build pipeline, which means I can't test this "properly". Could I ask you to build the package? I have a machine to test it on.

Also, would there be any interest in having proper Debian packaging? So that the package can be build using the standard Debian workflow. I might want to attempt it once I have a little more time, but I should ask in advance in case there is already a deliberate decision not to have it.

[Oleksiy-Yakovenko]

The build pipeline is configured to only build packages of releases with proper version number -- so I can't do it easily.
If you can't make your own package for your local needs -- you would need to find some other solution, like, not using a package and install using make install.

A question about the PR itself:

Is there a reason to do this as a separate .desktop file? Wouldn't it also work just fine if you add the new action to existing desktop file?

[dark-penguin]

I can do make install, but that won't confirm that the current build pipeline will pick up the new file properly when creating the package. That's what I wanted to test.

As I understand it, those "Actions" are additional items listed when you right-click the desktop entry. And what we want is not an "action" - we want a new "desktop entry" that can be assigned as an "installed application to open files with", and has applicable MIME types associated with it, and all that. That's how this is done in QMMP, where it works, and which I used as an example.

[Oleksiy-Yakovenko]

but that won't confirm that the current build pipeline will pick up the new file properly when creating the package.

I can confirm that this PR is not enough to include the new desktop file in the arch and deb packages.
In order to test this, you would need to do something like that:

1. assign some valid version number to the builds, by editing PORTABLE_VERSION file, and probably also configure.ac
2. download and unpack static deps bundle (see how travis/build.sh script does it)
3. run ./scripts/static_build.sh
4. run ./tools/packages/debian.sh or ./tools/packages/arch.sh

This should produce a deb package which you could then unpack and validate.

[dark-penguin]

I've managed to build the package - but only on Ubuntu 18.04, and only after modifying ./scripts/static_build.sh to skip building the GTK3 plugin, which was failing. On Ubuntu 22.04 the build was failing even after I've disabled most plugins - which is strange, because it builds just fine if I don't use that build pipeline.

To avoid saying "build fails" without the actual reason: the 18.04 build with GTK3 enabled failed with this:

clang: error: no such file or directory: './gtkui-gresources.c'
clang: error: no input files
Makefile:1385: recipe for target 'ddb_gui_GTK3_la-gtkui-gresources.lo' failed
make[3]: *** [ddb_gui_GTK3_la-gtkui-gresources.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/tmpfs/ubuntu18/deadbeef/plugins/gtkui'
Makefile:815: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/tmpfs/ubuntu18/deadbeef/plugins/gtkui'
Makefile:680: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmpfs/ubuntu18/deadbeef'
Makefile:545: recipe for target 'all' failed
make: *** [all] Error 2

Indeed, as I feared, the new file is not picked up - but the problem is not the packaging, it's automake:

make[2]: *** No rule to make target 'deadbeef-queue.desktop', needed by 'all-am'.  Stop.

And I've confirmed that you can NOT have multiple "desktop entries" in one .desktop file.

I'll be back once I get more familiar with autotools. 🙂 Unless you know how to fix that. I thought specifying the file in Makefile.am should be enough, but apparently it is not.