Use native file dialogs instead of Wine's

Questions about Wine on Linux
Locked
ewangreen4
Newbie
Newbie
Posts: 2
Joined: Fri Nov 26, 2021 3:05 am

Use native file dialogs instead of Wine's

Post by ewangreen4 »

In the Windows API, there are functions like GetOpenFileNameA(), GetSaveFileNameA(), etc. that will present a file dialog for the user to select a file to be opened/saved. In Wine, this will bring up Wine's re-implementation of the dialog, which is inconvenient, cumbersome to navigate, usually pretty ugly (depending on the settings), and overall not optimal for people who want a seamless Windows experience on a non-Windows platform. On Linux, xdg-desktop-portal or something similar could be used to achieve a more seamless effect by using the DE/WM's file dialog of choice for such situations; at the end of the day, it will provide the same file path, so why doesn't wine do this instead of its own solution? Has this been considered before?
jkfloris
Level 12
Level 12
Posts: 3136
Joined: Thu Aug 14, 2014 10:10 am

Re: Use native file dialogs instead of Wine's

Post by jkfloris »

Wine's developers don't often visit the forum. It's probably better to ask this question on IRC.
https://www.winehq.org/irc
Bamm
Level 4
Level 4
Posts: 136
Joined: Thu May 22, 2008 3:18 am

Re: Use native file dialogs instead of Wine's

Post by Bamm »

I want this too.
ssokolow
Newbie
Newbie
Posts: 1
Joined: Wed Feb 02, 2022 12:44 am

Re: Use native file dialogs instead of Wine's

Post by ssokolow »

There was a wine-devel discussion with a ChromeOS developer interested in using the portal APIs a few months after the last message here if anyone is interested.

The TL;DR: is that CodeWeavers did something similar by going straight to the GTK APIs, but you can't just enable it for all applications for the same reason GTK has a split between GtkFileChooser and GtkFileChooserNative. Some Windows applications want to customize the dialog.

Jactry Zeng said...
And the reason why our customer wants this just because they think Wine's
dialogs look not beautiful, they want to get rid of those. But Wine is improving its theming things, I expect Wine's dialogs can be better when this work finished, and then we don't need this GTK wrapper finally. So I didn't try harder to upstream it.
Other than that, I don't know if that or something similar will be accepted by Alexandre.
...so, if you want to argue for something like this, I'd argue it on grounds like integrating with the KDE/GTK Places/Bookmarks sidebars and making Wine more compatible with being run inside a Flatpak/Snap sandbox.
Locked