Using native Chrome OS FilesApp for file chooser

[Joel Hockey]

Thanks André, Andrew, Esme,

It sounds like at least I'm on the right track, but I guess any change
would need to be controlled on a per-app basis.

Is it typical to use a cmdline flag or an environment variable for
something like this?  E.g

  wine --file-dialog=xdg-desktop-portal notepad2.exe
or
  WINEFILEDIALOG=xdg-desktop-portal wine notepad2.exe

I'm guessing that WINEDLLOVERRIDES could be used if I fork the code and
produce my own version of comdlg32.dll, but I prefer not to maintain any
fork.

Does anyone have a feeling on whether wine would be happy to add an extra
option such as WINEFILEDIALOG?  I suppose if I get some patches done, I can
post them up and we can have further discussion.

For apps that want to customize the UI with a custom hook, I would either
have them fallback to the current UI, or ignore their requests for custom
hooks.  It may still be a better experience to use native FilesApp even
without the customizations.

On Tue, May 18, 2021 at 7:10 AM Esme Povirk (they/them) <
esme at codeweavers.com> wrote:

> I'd say the important ones are GetOpenFileName/GetSaveFileName, and
> the Common Item Dialog API introduced in Vista.
>
> With GetOpenFileName, applications can perform customizations by
> providing a hook procedure, which would be impossible to translate to
> another API. If an application provides a hook, it must be given a
> win32 dialog that has a specific layout.
>
> https://docs.microsoft.com/en-us/windows/win32/api/commdlg/nc-commdlg-lpofnhookproc
>
> The Common Item Dialog API also allows applications to perform
> customizations, but these are done through a COM interface which could
> be passed along to a native API that supported the same features:
>
> https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifiledialogcustomize?redirectedfrom=MSDN
>
> I'm guessing, though, that the dbus API does not provide for adding
> custom controls of any type to the dialog, so once again you would
> have to use a win32 dialog if the application requests customizations.
>
> At best, you're going to be able to replace the dialog in some
> applications but not others. To provide the functionality in the
> general case, I think you will need a shell extension, but that would
> result in some confusing UI. I don't think there's a good solution to
> this problem.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210518/623c8c17/attachment-0001.htm>