Mike Hearn mh@codeweavers.com writes:
I don't see how to make this work. Silently replacing the win32 file pickers with native file pickers (or custom built-for-Unix Wine pickers) is possible in a few cases but when the app modifies the dialog with additional controls, we have to use the same UI design as native.
Native file pickers are a completely different issue. What I'm talking about is the standard shell browser thing, except showing Unix paths instead of Windows drives, so that it's as transparent as possible to the app. If the app wants a GTK file picker it has to be changed to make GTK calls itself.
If we don't show Windows paths in the file pickers, I think this could be even more confusing that currently: programs will display eg Y:\MyDocument.doc in the titlebar but you will have chosen something under /home/xyz in the file picker.
Yes of course, we need to fix more than just the shell file picker. Some changes to the application code are probably unavoidable too, but this should be kept to a minimum. But we need something like that if we want to present Winelib as a credible environment for doing Linux ports.
Could you describe in more detail how you want this to work please? Having a new API that reuses as much code as possible while still presenting a sensible UI seems like the most direct way forward.
As you noted, the app can modify the dialog with additional controls etc. which is why we have to use the same API. If you have to change the whole file selection logic in the app code you might just as well convert it to GTK or whatever.