<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

[Mike Hearn]

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.