Allow launching .desktop files from the context menu.
Similar to issue #443 which proposes launching binaries/scripts from the context menu, this issue proposes doing the same for .desktop files, with the distinction that there would not be a terminal launched when the user does this.
Use cases
Some users have .desktop files for applications that they do not desire to integrate with the system, such as meticulously sorted folders full of .desktop files for games that would not be navigable in the OS's application launchers. These collections are likely to outlive the OS installation, being transferred from computer to computer, or live on an external hard drive. They are not really "installed" in any sense of the word.
In addition, the proposal in #443 as currently written would have a terminal appear for binaries/scripts launched in the manner it proposes. This is good for many use cases (for me, mostly development tools and scripts I've written myself), but not so nice for others, as the terminal may be pretty useless for some long-running programs such as firefox nightly or AppImages for full applications that aren't just quickly-completing scripts. One could always relegate the useless terminal off to another workspace to get it away from view, but it's still not so appealing. So programs that ship as tarballs intended to be used without installing could also ship a .desktop file which would enable them to be launched without a terminal.
There seem to be significantly fewer use cases for opening .desktop files from Nautilus however compared to opening binaries/scripts, which seems to be much more important functionality for users as evidenced by discussions here and on OMGUbuntu etc.
Desired behavior
Similar to the proposal in issue #443, one would be able to launch a .desktop file from the context menu, something like "Launch .desktop file" or "Launch program". Identical semantics as in issue #443 could be used, with a confirmation dialog that would warn of risk and set the execute bit if the user confirms.
.desktop files would still have their extension displayed. Double-clicking a .desktop file would open it as any other file, in a text editor. Personally when I look at .desktop files in Nautilus I almost always want to edit them, not run them, and their special treatment has tripped me up trying to do this in the past. So the same 'open' vs 'launch/execute' distinction as is being discussed in issue #443 in the context of executable text files is also very useful for .desktop files.
Benefits of the solution
It allows users with their folders full of games to be able to organise them as they like, keep them on an external hard drive, and still have icons to be able to recognise their games.
It enables distributors of tarballs to give a way of launching the app from Nautilus that will not open a terminal.
As with the proposal in issue #443, it makes a sharper distinction between 'open' and 'execute', decreasing the likelihood that a user will execute a program by accident or be misled into doing so, and allows muscle memory to develop based on this distinction such that the user is more likely to be able to consistently choose the option they want, either to edit a .desktop file or launch it .
The risk that a user will be misled into running a malicious program is lower compared to Nautilus's current behaviour of launching .desktop files on double click. If a user double clicks a .desktop file under this proposal, it will just open in a text editor.
This approach allows people to continue to self-manage certain applications separately from the OS, though it is controversial as to whether this is a benefit or a drawback.
Possible drawbacks
This approach will not hide the terminal for AppImages, as they're executables, not .desktop files. The issue of organising folders of large numbers of .desktop files that the user wants to keep separate from OS-installed applications might be better addressed by changes to the shell that allow adding custom applications folders, such that the user's folders full of games could become a hierarchy of launchers in the shell rather than the file browser.
The presence of a custom icon on .desktop files continues to have the potential to mislead users into thinking a file is something it isn't - though the requirement to open a context menu to launch it and the warning popup seems to mitigate the risk substantially.
Repeating the above, this approach allows people to continue to self-manage certain applications separately from the OS, though it is controversial as to whether this is a benefit or a drawback.