when gvfs is unable to provide a gvfs replacement location for files not in the local file system (eg. when accessing an ssh:// location, but the user is not in the fuse group), opening files with programs that have an `Exec $PROGRAM_NAME %f` style line in their desktop entry results in the program being openend without a filename passed.

this is confusing users (which just don't get their files opened) and sysadmins (which don't get error messages).

imo, the following behavior would be ideal:

* open-with-other-application menu: only show applications of %u, %U and %k type, or gray out %f/%F applications. if any of the latter are present, add this line above the custom command section:

  "Some applications are not available for this location. In order to support them too, please see the [documentation on activating gvfs-fuse]."

  where the link should point to the respective manual page (to-be-created; possibly, distributions would want to override that location).

  the documentation might read like this, initially:

    For files that do not reside in the local file system (eg. files on network shares), a subsystem called "GVFS FUSE" is required in order to open them with regular applications. If that subsystem is not operational, only particular applications are able to access those files.

    If you can not open files in remote locations in some programs, please check the following:

    * Is GVFS built and installed with FUSE support? Is FUSE installed on your system? (Especially: Does a device called `/dev/fuse` exist?)
    * Do you have permission to use FUSE? (Precisely: Do you have write access to `/dev/fuse`?)
    * Is GVFS FUSE explicitly disabled by a `--no-fuse` option to gvfsd, or by the environment variable `GVFS_DISABLE_FUSE`?
    * Do you have permissions to create a mount point at `/run/user/<UID>/gvfs` (or the fallback location `~/.gvfs`)?

    For developer documentation on that topic, see <https://wiki.gnome.org/Projects/gvfs/doc>.

* right-click open-with-menu: gray out %f/%F options. users who wonder can reasonably be assumed to resort to the "other" item option at the bottom of the list, where they'll find more hints.

* double-click action: if the default application is a %f/%F application, present a dialog box:

  "The application '%{NAME}' is not available for this location. In order to support it too, please see the [documentation on activating gvfs-fuse]."

  the box should have an "ok" and a "open with other application" button.

admittedly, that's quite complex behavior for a bug that primarily occurs when users are not in the fuse group, when gvfs-fuse is not installed or was disabled at build time, or on operating systems where fuse is not available. therefore, always presenting the dialog whenever a %f application is invoked (independently of whether it's by double-click action, by "open with" or by "open with other"), is a viable simplification.


for development, this behavior can be invoked by chowning the /run/user/${UID}/gvfs directory to root, and pkill'ing all gvfs processes. beware that unmounting the gvfs directory while gvfs is left running does produce a different effect, being that the %f program is invoked with a path that doesn't exist (as gvfs does not notice the mount point going away). i think that this different case can be ignored for the purpose of determining whether comaptibility paths are available or not, as it only happens when provoked (as opposed to the original case, which is documented as "g_file_get_path [returns] string containing the GFile's path, or NULL if no such path exists").