Hi Joel,

I also did some tries for adding a GTK wrapper for GetFileName/GetSaveFileName when I worked for a CrossOver porting.
I used registry ("HKCU\Software\Wine\GTK Wrapper" and "HKCU\Software\Wine\AppDefaults\app.exe\GTK Wrapper") for toggling this feature. So that we can only enable this feature for specific applications.
You can find the patches in https://gitlab.com/jactry/wine-git/-/tree/gtk3wrapper .

On 5/18/21 11:34 AM, Joel Hockey wrote:
> I'm not especially familiar with GTK, but my understanding is that the
> xdg-desktop-portal dbus APIs were created to solve this problem.
>
> https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html
>
> GtkFileChooserNative was created as a replacement for
> GtkFileChooserDialog.  When it detects that there is a native dialog
> provided (gtk, kde, wlroots) it will use it.  My plan is to add a server
> implementation for cros FIlesApp.  Hopefully linux apps which support
> xdg-desktop-portal will then use the native dialog, and I would also like a
> way for wine apps to do similar.
>
> On Tue, May 18, 2021 at 12:00 PM Esme Povirk (they/them) <
> esme@codeweavers.com> wrote:
>
>> How is this controlled in toolkits like GTK? If they don't need an
>> environment variable then neither should Wine.
>>
>>> 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.
>>
>> Well, the problem with the hook function in particular is that
>> applications may break without it. For the common item dialog, it
>> depends entirely on what the custom options do, this may represent a
>> loss of important functionality.
>>
>> I could see providing an override if users know that it works in their
>> application, but I don't think that should be done by default.
>>