The reference xdg-email shell script documents that it supports mailto:
URIs, and it appears that at least Chromium and Jami (formerly GNU Ring)
genuinely make use of that feature.
If the only non-ignored argument is a mailto: URI, we pass it
directly to the OpenURI portal without further processing. This mode
can be used by applications wishing to do tricky things with headers
that we don't directly support.
Otherwise, we parse the mailto: URI and extract the header, subject
and addresses. Other headers are ignored.
The reference xdg-email script only accepts one mailto: URI, but
accepting more than one is actually easier than not, so we do that.
Branch based on #31 to get the tests to pass. Only the last commit is new here.
One slightly weird thing in the current implementation is that with the stable (1.6.x) version of xdg-desktop-portal, calling OpenURI for a mailto: URI prompts to choose an app, whereas ComposeEmail goes directly to the composer app. This is fixed in the 1.7.x development branch.
The reference xdg-email shell script documents that it supports mailto: URIs, and it appears that at least Chromium and Jami (formerly GNU Ring) genuinely make use of that feature.
If the only non-ignored argument is a mailto: URI, we pass it directly to the OpenURI portal without further processing. This mode can be used by applications wishing to do tricky things with headers that we don't directly support.
Otherwise, we parse the mailto: URI and extract the header, subject and addresses. Other headers are ignored.
The reference xdg-email script only accepts one mailto: URI, but accepting more than one is actually easier than not, so we do that.
Resolves: https://github.com/flatpak/flatpak-xdg-utils/issues/19
Branch based on #31 to get the tests to pass. Only the last commit is new here.
One slightly weird thing in the current implementation is that with the stable (1.6.x) version of xdg-desktop-portal, calling OpenURI for a
mailto:
URI prompts to choose an app, whereas ComposeEmail goes directly to the composer app. This is fixed in the 1.7.x development branch.