<<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]

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