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

[Alexandre Julliard]

Mike Hearn <mh at 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.

-- 
Alexandre Julliard
julliard at winehq.org