Questions about a unified API for file choosers (and platform/toolkit integration)

[Matthew Paul Thomas]

Roman Hargrave wrote on 23/03/17 21:30:
>…
> Now, if there were a toolkit-agnostic set of interfaces for
> applications to call in to in order to prompt the user with the native
> file picker instead of that which the toolkits use would have the
> advantage of insuring that any settings applied by their desktop
> environment follow through to the application experience, thus
> allowing users to, for instance, not be subjected to, for instance GTK
> file picker if they would prefer to use the Qt picker.
>…

I understand the desire to swap out one toolkit’s file picker for
another. However, many apps legitimately embed custom UI into the file
picker. For example:

*   LibreOffice’s Open dialog includes a “Version:” menu for opening
    versioned documents. The contents of the menu changes dynamically
    to list the versions of the selected document, and it is disabled
    whenever the document has only one version.

*   LibreOffice’s Save dialog includes a “Save with password” checkbox.
    The checkbox becomes disabled and unchecked whenever you choose a
    file format that doesn’t have that feature.

*   Gimp’s Open dialog includes a list of image formats so that you can
    override the auto-detected format if necessary.

*   Geany’s Open dialog includes menus for manually specifying the
    encoding as well as the filetype.

If any “toolkit-agnostic set of interfaces” was not capable of these
things, developers of apps like these would have to not use it, drop
features, or resort to a separate dialog before/after the file picker,
annoying all users for the sake of a few.

On the other hand, if any set of interfaces *was* capable of these
things, it would be similar in complexity to a toolkit. So app
developers would need to learn — and maintain code in — one toolkit plus
one quasi-toolkit, when they could be spending that extra
learning+maintenance time on features or bug fixes instead.

-- 
mpt