Support TryExec key like in .desktop files

[elementaryBot]

Contractor should support a TryExec key like in .desktop files, see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html

This is an extension of bug 912413 required for properly handling contracts that use an wrapper over the actual provider - which will happen very often, as far as I can tell.

Launchpad Details: #LP1171835 Sergey "Shnatsel" Davidoff - 2013-04-23 12:10:34 +0000

[elementaryBot]

This is good and easy to implement but at the same time it encourages bad/lazy system integration. Package dependencies should do it. A "wont fix" IMHO.

Launchpad Details: #LPC Victor Martinez - 2013-05-01 21:42:30 +0000

[elementaryBot]

I'd like to be proven wrong though :)

Launchpad Details: #LPC Victor Martinez - 2013-05-01 21:43:59 +0000

[elementaryBot]

Example: Inkscape. It requires a wrapper script for contracts to function properly, but the presence of the script does not guarantee the presence of Inkscape. In theory it should, BUT unfortunately there's no way we can make installing Inkscape also install the package with contracts. So until we upstream the contracts we have 3 options:

1. Let the user discover the existence of a separate contracts package and install it manually (not realistic)
2. Patch Inkscape package to either include the contracts or recommend the contracts package (cumbersome)
3. Check presence of actual Inkscape binary from TryExec=

Launchpad Details: #LPC Sergey "Shnatsel" Davidoff - 2013-05-02 00:33:08 +0000

[elementaryBot]

I added initial support for TryExec to fix another bug by the way.

Launchpad Details: #LPC Victor Martinez - 2013-05-03 20:21:27 +0000

[drowsymike]

Hello. Is this task still active?

I was thinking I could try writing a check for the presence of a binary executable (using Inkscape as an example – the main Inkscape binary itself). This might not cover all possible system and user program configurations, but it could at least help with applications whose binaries are located in standard system directories.

Am I correct in understanding that the main actions should occur in Contractor itself? That is, it should check for the presence of the main binary file, or something like that. If the contract file (or both the contract file and the binary file) is missing, a window like "Select a program to work with files" should appear?

[danirabbit]

To be honest contractor is kind of a dead project. It was developed before the world of Flatpak and Wayland and sandboxes and never widely adopted outside of elementary

Probably what needs to happen is to:

• pursue extending the desktop launcher specification to include actions that can take arguments, since desktop files are exported from Flatpak
• Then try to get a mechanism for exposing these actions into XDG portals. Likely what contractor does now of giving the results directly won't be okay because it means apps would be able to scrape this data and fingerprint users. So it would probably need to be like a generic share sheet portal and then our implementation of the share sheet portal would list these actions as options

[drowsymike]

If Contractor is largely obsolete technology already (given the availability of Flatpak apps and the rest you mentioned), should I look into Granite's interaction with XDG portals instead?

[danirabbit]

Granite isn't really relevant here since granite runs inside the sandbox as part of the application and a replacement for contractor would need to run on the host.

Probably the most relevant discussion is flatpak/xdg-desktop-portal#12