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.