On Mon, 2004-12-06 at 17:07 +0100, Alexandre Julliard wrote:
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.
Hmm. For the winecfg use case though we have to pass back a Unix path, as by definition it might not be mapped to a Windows path. I suspect most code that uses the browse folder API converts the PIDL straight into a path that it can use with CreateFileEx and so on so it might break stuff if we invented a new PIDL extension that contained a raw Unix path.
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.
OK, I agree with that. Still there are stages of porting - simply having it run like it would on regular Wine+EXE is the first stage, then dressing it up to integrate better with Unix is the next, then porting to native (well, free) APIs where possible would be the final stage.
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.
OK. I'm still not sure exactly what type of API extension is wanted though. From looking at the relevant page on MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en- us/shellcc/platform/shell/reference/structures/browseinfo.asp
there could be a new Unix FS shell namespace plugin that is normally hidden (how? i'm not sure the API lets you do that) which you can set as the root and select from there, and then some way to convert a PIDL back into a Unix path. Still, there is the problem that PIDLs are not usable with the file APIs, so the sort of thing winecfg does will be rare. And if you let the user pick any directory it may not be mapped.
So maybe when the user selects a path under the root, a drive could be automatically mapped temporarily and the PIDL would be convertible to the newly mapped drive using SHGetPathFromIDList.
Still, given that it'd normally be hidden (otherwise you get both the windows and unix view of the FS at once in the file|open dialog box...) this seems like an awful lot of work for the case of specifically written apps like winecfg. I'm not sure it's worth trying to hide the user from the fact that the program uses drive letters under the hood.