Drive detection should be done in winecfg (in a way that can be invoked from wineprefixcreate), since people may want to update parts of their drive config without rebuilding the whole .wine directory.
Hmm. I noticed that wineprefixcreate has an --update option. I assumed that meant it would rescan the system and non-destructively update the links.
Thinking about it, I suppose we need getmntent which is a bit tricky to duplicate in shell. So it has to be written in C. Ugh.
By the way, I was working on winecfg some more last night. I'm still not sure what the exact plan is for config migration.
What'd be best from my point of view (winecfg) is to move the config heirarchy from eg
HKLM/Software/Wine/Wine
to
HKLM/Software/Wine/Config
or somewhere else, anywhere really, the key is keeping the current structure and layout. That also has the advantage that users are familiar with the current layout so it's less of a shock when the config file disappears, there's no need to consult a big list to find out where a setting went.
Currently there is code like this:
set(keypath("x11drv"), "Desktop", "640x480")
which will do the right thing w.r.t global settings/appdefaults. This is convenient for people adding new settings to the program as well as keeping the code fairly clean (apply/cancel is implemented as an overlay on top of the registry and it works well).
This becomes somewhat less convenient if things are scattered around everywhere, especially if appdefaults no longer mirror the global settings heirarchy.
So is the plan to copy the config branch to a different branch, or to do each setting individually? If the latter, why?
thanks -mike