Early support for macOS

[fathonix]

Arqiver are already buildable on macOS without any modification, but lacks an icon and a list of associated files to make it show up on the "Open With" menu. This PR addresses those issues.

TODO

• Add more supported files in Info.plist
• Change qmake and CMake files to set the right version (and maybe bundle identifier) in Info.plist
  (currently only qmake)
• Add support for opening files (Info.plist only registers supported files but the file isn't actually opened)
• Append the executable directory to the process' PATH env on macOS to detect 7z executable if bundled
• Use Qt native method or the open command instead of gio on macOS

[tsujan]

Thanks for the macOS support! Please tell me when it's complete (I don't have macOS).

Since libarchive, 7z and gzip are the run time dependencies, do they exist in macOS?

Use Qt native method or the open command instead of gio on macOS

The current code uses Qt's native method when gio doesn't exist. Linux installations may also lack gio. Arqiver doesn't depend on gio; it just uses it if existing because it's more reliable. So, I don't think any change is needed here.

[fathonix]

Since libarchive, 7z and gzip are the run time dependencies, do they exist in macOS?

BSD tar and gzip are preinstalled on macOS but 7z isn't.

I've been able to append QCoreApplication::applicationDirPath and setenv it to PATH at runtime to detect 7z but Arqiver shows "Could not read archive" not "7z is missing from your system". If it uses 7z from a package manager, it works. I'm still working on this one.

The current code uses Qt's native method when gio doesn't exist. Linux installations may also lack gio. Arqiver doesn't depend on gio; it just uses it if existing because it's more reliable. So, I don't think any change is needed here.

It's a problem when gio exists on macOS, it's not functional and throws error gio: file:///path/to/file: Operation not supported for the current backend. I can confirm the Qt native function is working but Arqiver seems doesn't fall back to when gio returns exit code 2.

What the bundle identifier should be, btw? It's in reverse-DNS style like Flatpak's Application ID.

[tsujan]

What the bundle identifier should be, btw? It's in reverse-DNS style like Flatpak's Application ID.

Sorry, I don't understand the question. As I said, I don't have macOS, and so, don't know anything about it.

I don't use Flatpak either (actually, I run away from such things). It's Flatpak's job to work correctly, not an app's job to conform to it. Any kind of packaging should be done downstream.

EDIT:
A friend of mine told me it can be com.github.tsujan.arqiver.