when shell32.dll is registered during wineprefixcreate, it puts a lot of paths based on Z:\ in HKLM/HKCU Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. This is due to resolving CIDL_PERSONAL to the DOS path corresponding to $HOME.
If people remove the Z: drive afterwards, this leads to a lot problems (One being that the Desktop shellfolder won't initialize any more, which breaks the complete shell namespace and thus the file dialogs).
Yeah, that is painful.
I'm proposing to add two more environment variables: %PERSONAL%, which would be expanded to the DOS path corresponding to $HOME if this exists, or to %USERPROFILE%\My Documents if not (with "My Documents" resource based, of course). And %DESKTOP%, which would be expanded to DOS_PATH_OF($HOME)\Desktop if existent and to %USERPROFILE%\Desktop, if not.
So the environment variable expansion would be based on shell32? Ouch. I don't think that'll fly.
I'm of the opinion that all this fancy CSIDL_PERSONAL mapping doesn't belong in shell32, even though I put it there. shell32 should default to creating paths that are part of the profiles directory if nothing else exists, since the shell won't work without them. But creating Linux-environment-friendly defaults should perhaps go in wineprefixcreate. I actually rather liked the idea of putting it in winecfg, and launching winecfg in a GUI-less mode from wineprefixcreate. The advantage is that the drive mappings and shell folder creation would be in the same app, and so would have some hope of staying consistent.
If a user breaks it through direct registry manipulation, his fault. If she breaks it through normal use of our tools, our fault.
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hey Juan,
On Wednesday 25 January 2006 17:03, you wrote:
I'm proposing to add two more environment variables: %PERSONAL%, which would be expanded to the DOS path corresponding to $HOME if this exists, or to %USERPROFILE%\My Documents if not (with "My Documents" resource based, of course). And %DESKTOP%, which would be expanded to DOS_PATH_OF($HOME)\Desktop if existent and to %USERPROFILE%\Desktop, if not.
So the environment variable expansion would be based on shell32? Ouch. I don't think that'll fly.
Just submitted a patch for the %DESKTOP% case. Could you have a look at it and tell me what you think? Are you afraid of name clashes?
Bye,
Juan Lang juan_lang@yahoo.com writes:
I'm of the opinion that all this fancy CSIDL_PERSONAL mapping doesn't belong in shell32, even though I put it there. shell32 should default to creating paths that are part of the profiles directory if nothing else exists, since the shell won't work without them. But creating Linux-environment-friendly defaults should perhaps go in wineprefixcreate. I actually rather liked the idea of putting it in winecfg, and launching winecfg in a GUI-less mode from wineprefixcreate. The advantage is that the drive mappings and shell folder creation would be in the same app, and so would have some hope of staying consistent.
Maybe what we should do is to always have the paths point into the c: drive, and then play with symlinks at the Unix level to redirect things to $HOME. This way it would keep working even if the drive config is changed after the initial setup.
Maybe what we should do is to always have the paths point into the c: drive, and then play with symlinks at the Unix level to redirect things to $HOME. This way it would keep working even if the drive config is changed after the initial setup.
I like this suggestion, though I'm hoping someone else will code it :)
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wednesday 25 January 2006 17:36, Alexandre Julliard wrote:
Maybe what we should do is to always have the paths point into the c: drive, and then play with symlinks at the Unix level to redirect things to $HOME. This way it would keep working even if the drive config is changed after the initial setup.
For some reason I thought that by default wine isn't following symbolic links to directories, but that doesn't seem to be true any more. Is this option still available? Do we still have to consider this?
I would go on to extend winecfg then, to support setting symbolic links for the "Desktop" and the "My Documents" folders. And add a command line option to set reasonable defaults in a GUI-less mode to be called from wineprefixcreate.
Is it ok to rename winecfg's "Appearance" tab to "Desktop Integration" and put this stuff there?
Bye,
Michael Jung mjung@iss.tu-darmstadt.de writes:
For some reason I thought that by default wine isn't following symbolic links to directories, but that doesn't seem to be true any more. Is this option still available? Do we still have to consider this?
There's no longer an option, symlink loops are now detected automatically. It means a symlink to $HOME won't show up in directory searches, but I doubt this would be a major problem.
I would go on to extend winecfg then, to support setting symbolic links for the "Desktop" and the "My Documents" folders. And add a command line option to set reasonable defaults in a GUI-less mode to be called from wineprefixcreate.
Support in winecfg would be good, but I think we still want shell32 to be able to set proper defaults, especially if a wrong setup means file dialogs don't work anymore.
On Thursday 26 January 2006 12:19, Alexandre Julliard wrote:
Support in winecfg would be good, but I think we still want shell32 to be able to set proper defaults, especially if a wrong setup means file dialogs don't work anymore.
As I understood thus far our plan is to remove all the $HOME magic from shell32 and let CSIDL_PERSONAL default to %USERPROFILE%\LoadString(IDS_PERSONAL) and CSIDL_DESKTOP to %USERPROFILE%\LoadString(IDS_DESKTOPDIRECTORY).
My current plan is to move all the unix symlink stuff to winecfg. We could call winecfg from wineprefixcreate to set up the symlinks. It would still work without the symlinks. With Desktop and MyDocuments being mapped into the profile directory, though.
Do you see any problems with this?
Bye,
Michael Jung mjung@iss.tu-darmstadt.de writes:
On Thursday 26 January 2006 12:19, Alexandre Julliard wrote:
Support in winecfg would be good, but I think we still want shell32 to be able to set proper defaults, especially if a wrong setup means file dialogs don't work anymore.
As I understood thus far our plan is to remove all the $HOME magic from shell32 and let CSIDL_PERSONAL default to %USERPROFILE%\LoadString(IDS_PERSONAL) and CSIDL_DESKTOP to %USERPROFILE%\LoadString(IDS_DESKTOPDIRECTORY).
My current plan is to move all the unix symlink stuff to winecfg. We could call winecfg from wineprefixcreate to set up the symlinks. It would still work without the symlinks. With Desktop and MyDocuments being mapped into the profile directory, though.
Do you see any problems with this?
Yes, I think shell32 should take care of making sure the directories exist, and creating sane defaults if they don't. Moving things to winecfg wouldn't prevent file dialogs from getting broken if users move directories around.
On Thursday 26 January 2006 13:15, Alexandre Julliard wrote:
Yes, I think shell32 should take care of making sure the directories exist, and creating sane defaults if they don't. Moving things to winecfg wouldn't prevent file dialogs from getting broken if users move directories around.
Please find attached what I've been working on. The patch to shellpath.c is trivial. It just removes the $HOME mapping magic. This means it will create all necessary directories in the user's profile, as it probably was before Juan's patches. So this should work without problems, but with the disadvantage that it won't map to $HOME anymore.
With the patch to winecfg, the user can select where to link 'Desktop' and 'My Documents' to. I don't see why things should break, as long as the user doesn't fiddle with registry settings.
Of course, we should probably set up symlinks to $HOME in wineprefixcreate, which is not implemented yet. Should not be too much work, though.
Sorry for the huge winecfg patch, but most of it is due to resource updates.
Could this go into cvs?
Bye,
-
Alexandre Julliard -
Juan Lang -
Michael Jung