RFC: more Windows-NT like user directories?

Mike Hearn m.hearn at signal.QinetiQ.com
Tue Sep 21 03:52:29 CDT 2004


> 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




More information about the wine-devel mailing list