Alexandre Julliard wrote:
I'm afraid so yes. We really don't want to define new APIs for that, it needs to be integrated properly with the existing code. Ideally a Winelib app should be able to start using Unix dialogs without code changes at all.
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.
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.
If we did a shell extension to simply reflect the Unix heirarchy into the shell namespace, then the map drive dialog that motivated all this would display both currently mapped drives *and* the custom namespace extension, which would allow invalid selections (or at the very least, be quite confusing). It would also imply a large amount of code (IShellFolder implementations etc) to achieve the same effect that introducing a new function has.
We could reuse the rather nice GTK+ file pickers, which were recently redesigned and support things like bookmarks and pluggable devices, however that'd make winecfg (and therefore Wine) depend on GTK+ which in the past you objected to.
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.
thanks -mike