A standard for file browser widgets

[Soni L.]

I'd like to propose the following standard for file browser widgets:

---

# File Browser Widget Standard

Users should be able to choose and customize file browser dialogs to fit 
their needs. Currently users have multiple file browser dialogs they 
need to customize, and some that they are unable to customize due to 
being straight-up hardcoded. This specification is meant to solve that 
particular accessibility nightmare.

This specification proposes xdg-settings default-file-browser to select 
an application for file browser dialogs. The value must be the name of a 
desktop entry as defined in the "Desktop Entry Specification", with 
groups defined in this specification. This specification defines the 
groups [File Browser] and [Files Browser]. A compliant application must 
declare both. If an application only declares one or the other, it 
should not be used.

## The [File Browser] group

The [File Browser] group is used when the user needs to select a single 
file. This should be used when saving a file, or opening a file in an 
application that can't handle multiple files.

The [File Browser] group must have an Exec key containing a single %u to 
be used as the default selected path. If no particular default path is 
desired, a single hyphen-minus, "-", should be used.

The Exec command must output the full path of the user's selection to 
stdout, and exit successfully. A non-successful exit indicates that the 
user closed the dialog or canceled the operation.

## The [Files Browser] group

The [Files Browser] group is used when multiple files may be selected at 
once. This should be used when opening multiple files at once is possible.

The [Files Browser] group must have an Exec key containing a single %U 
to be used as the default selected paths. If no particular default path 
is desired, it should be omitted. In particular, a single hyphen-minus, 
"-", should not be used.

The Exec command must output the full paths of the user's selection to 
stdout, NUL-separated and optionally NUL-terminated, and exit 
successfully. A non-successful exit indicates that the user closed the 
dialog or canceled the operation.