<div dir="ltr">I'm not especially familiar with GTK, but my understanding is that the xdg-desktop-portal dbus APIs were created to solve this problem.<div><br></div><div><a href="https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html">https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html</a><br></div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 18, 2021 at 12:00 PM Esme Povirk (they/them) <<a href="mailto:esme@codeweavers.com">esme@codeweavers.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How is this controlled in toolkits like GTK? If they don't need an<br>
environment variable then neither should Wine.<br>
<br>
> 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.<br>
<br>
Well, the problem with the hook function in particular is that<br>
applications may break without it. For the common item dialog, it<br>
depends entirely on what the custom options do, this may represent a<br>
loss of important functionality.<br>
<br>
I could see providing an override if users know that it works in their<br>
application, but I don't think that should be done by default.<br>
</blockquote></div>