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