Using native Chrome OS FilesApp for file chooser
I'm one of the Chrome OS developers. I would like to make it possible for wine apps running in the crostini linux VM to use the Chrome OS native FilesApp for file chooser when possible. Using the native FilesApp improves the UX consistency, and also allows us to let VM apps get access to files outside the VM which can be shared on-demand when a user selects. Does wine already have any APIs where a native file chooser dialog can be configured either during compile or at runtime? I don't see anything. I've been looking at the possibilities today, and doing some testing using Notepad2.exe (since it is the simplest windows app I know). I see that it calls GetOpenFilenameW() to launch a file chooser which is implemented in dlls/comdlg32/filedlg.c GetFileDialog95(). Do most (all) apps use this same API for a file chooser? Would GetFileDialog95() be a possible place to call out to a native file chooser? I'm not familiar with this space, but I've discovered today that xdg-desktop-portal dbus APIs (org.freedesktop.portal.FileChooser) could be a suitable approach. https://github.com/flatpak/xdg-desktop-portal I'm planning to look at this a little more and try and get some code running soon. I can send some patches then, but any help now to point me in a good direction is appreciated. Thanks Joel
Hi Joel, Am 17.05.21 um 12:22 schrieb Joel Hockey:
I'm one of the Chrome OS developers. I would like to make it possible for wine apps running in the crostini linux VM to use the Chrome OS native FilesApp for file chooser when possible. Using the native FilesApp improves the UX consistency, and also allows us to let VM apps get access to files outside the VM which can be shared on-demand when a user selects.
Does wine already have any APIs where a native file chooser dialog can be configured either during compile or at runtime? I don't see anything.
AFAICT no
I've been looking at the possibilities today, and doing some testing using Notepad2.exe (since it is the simplest windows app I know). I see that it calls GetOpenFilenameW() to launch a file chooser which is implemented in dlls/comdlg32/filedlg.c GetFileDialog95(). Do most (all) apps use this same API for a file chooser?
I would think so yes
Would GetFileDialog95() be a possible place to call out to a native file chooser? I'm not familiar with this space, but I've discovered today that xdg-desktop-portal dbus APIs (org.freedesktop.portal.FileChooser) could be a suitable approach. https://github.com/flatpak/xdg-desktop-portal <https://github.com/flatpak/xdg-desktop-portal>
One issue you will face here is that some applications want to modify the "file open/save window". IIRC adding special buttons and so on.
I'm planning to look at this a little more and try and get some code running soon. I can send some patches then, but any help now to point me in a good direction is appreciated.
Thanks Joel
On Mon, May 17, 2021 at 08:22:01PM +1000, Joel Hockey wrote:
I'm one of the Chrome OS developers. I would like to make it possible for wine apps running in the crostini linux VM to use the Chrome OS native FilesApp for file chooser when possible. Using the native FilesApp improves the UX consistency, and also allows us to let VM apps get access to files outside the VM which can be shared on-demand when a user selects.
Does wine already have any APIs where a native file chooser dialog can be configured either during compile or at runtime? I don't see anything.
This is something we've done in CrossOver for our some of our macOS ports. Looking at our source, the places where we call into native code are GetOpenFileName and GetSaveFileName in comdlg32, and SHBrowseForFolder in shell32. It looks like we actually don't change GetFileDialog95 at all. Like André said, your biggest difficulty will be many applications expect these dialogs to be and behave like real Windows dialogs, so this kind of hack doesn't work for every application. For example they might walk the window tree to find some internal control to mess with; and they can specify custom dialog templates and hook functions, which are difficult or impossible to support with a native dialog. It's not something you can safely turn on for all applications. Andrew
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-lpofnh... 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... 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.
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(a)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-lpofnh...
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...
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.
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.
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(a)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.
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(a)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.
Wow Jactry, that looks pretty much exactly what I want. It looks like you are using gtk_file_chooser_dialog_new. Do you know if it would work the same to use gtk_file_chooser_native_new which can then use xdg-desktop-portals? It looks like the APIs are similar. I believe they are intended to be similar/same. https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html I will see if I can get a dbus server implementation working, and then hopefully I can patch in your changes and modify to use gtk_file_chooser_native_*. Do you expect your changes to be merged into wine? On Tue, May 18, 2021 at 2:03 PM Jactry Zeng <jzeng(a)codeweavers.com> wrote:
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(a)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.
On 5/18/21 12:17 PM, Joel Hockey wrote:
It looks like you are using gtk_file_chooser_dialog_new. Do you know if it would work the same to use gtk_file_chooser_native_new which can then use xdg-desktop-portals? It looks like the APIs are similar. I believe they are intended to be similar/same.
https://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html Yeah, it is possible, here is a quick test: https://gitlab.com/-/snippets/2121950 .
I will see if I can get a dbus server implementation working, and then hopefully I can patch in your changes and modify to use gtk_file_chooser_native_*.
Do you expect your changes to be merged into wine?
I don't think so. That is very experimental, it may be very buggy, I only tested it with very limited applications. 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.
participants (5)
-
Andrew Eikum -
André Hentschel -
Esme Povirk (they/them) -
Jactry Zeng -
Joel Hockey