Optionally map the unix filesystem instead of drive letters into the shell namespace

[Michael Jung]

On Monday 30 May 2005 02:12, you wrote:
> Please explain on the per process basis. If you mean let winelib
> application change the global flags via wine API, there will be
> synchronization and threading issues. Say application A turn on unix path,
> application B turn on unix path, application B exit and turn off unix path,
> then application A will now be back in dos path. 
> Or do you mean each application would have their own registry setting 
> and this per application setting is set when application is installed? Then
> there is problem of how wine get to this application specific settings.

The ShowUnixFilesystem option in the registry could be global or application 
specific. In the current patch it's global. But it could be something like

[AppDefaults\\winword.exe\\shell32]
"ShowUnixFilesystem" = "1"

which would turn it on only for winword (This syntax is common in wine's 
config file).

Back to the winelib case. Suppose the user did choose not to display the unix 
filesystem at all. We could implement an API, say show_unix_filesystem(BOOL 
on), which would turn the feature on for the current process, no matter what 
the user chose in the registry. (By setting the option_show_unix_filesystem 
variable, which currently is in scope only in the show_unix_filesystem 
function, but valid process-wide).

> What I mean here is when user is browsing unix path and be able to type
> in dos path seems a bit strange. Just the little things that doesn't make it
> feel really in unix mode for winlib app.

You mean like the user types in "Z:\home\mjung\" and thinks: "Gosh, this 
should work only for unix paths. What did those crazy wine hackers think?". 
In my opinion, this is really a no-problem. The user should be able to enter 
unix paths, that's for sure (it doesn't work currently, though, but should be 
relatively easy to fix). But the possibility that the user enters a dos path 
by accident and then wonders why this works is pretty low, I think.

> Sorry if I offended you, that wasn't my intention. Initially it was just
> a direct email sent to Alexandre to ask the status of the patch I previously
> sent. If it has been rejected, I would like to know the reason so I can make
> changes and send in another patch. Should have cc wine-devel, my apologies.

Never mind. In your last mail you said that you already implemented "rename" 
and "new folder" functionality. Are those restricted to shfldr_unixfs? Do you 
think those could be sent as a separate patch already? That would be sweet.

Bye,
-- 
Michael Jung
mjung at iss.tu-darmstadt.de