config converting problem
m.hearn at signal.qinetiq.com
Wed Aug 11 09:57:52 CDT 2004
PS I've added wine-devel back as from the wording it sounded like it was
meant to go there: wine-devel is one of these annoying old-skool lists
which don't rewrite Reply-To, but that rant is something for another time :)
Holly Bostick wrote:
> Yeah, fine, "it sucks"-- and I admit that I myself never install to
> "C:\Program Files", under Windows or Wine, but geez guys-- who do you
> think your users are when you say things like this?
> They're *Windows users*. And that means they probably use the defaults,
> and that means that their whole data tree is in ./wine. And if that data
> tree meant so much to them that they installed Wine in the first place,
> it's kinda cold to say "just blow it away".
Well, I'd guess that most users run perhaps one or two apps in Wine at
the most, unlike Windows users who run lots and lots of apps. So every
so often reinstalling these programs is not such a big deal, unless you
have things like the Office XP activation scheme which don't like that.
> They're non-technical (a behaviour encouraged by being a Windows user).
> So while I'm sure they're used to "blowing away" their Windows
> installation regularly (due to the "non-technical" nature of things like
> My Documents rather than putting your bloody docs on another partition
> rather than C:\, for example), since half the reason to move to Linux is
> to put an end to that necessity, it seems a bit odd to reinstate it here.
Yeah, I agree that at minimum we should force My Documents elsewhere,
and maybe have wineprefixcreate link H: to $HOME along with putting a
label on that drive saying "Save Your Files Here" (or whatever).
> Wouldn't it just make more sense to *separate the config files from the
> (wine) system files*?? Why in the heck is fake_windows in the ./wine
> directory anyway???
Good question. I suspect the answer is "because it's always been there" :)
> 1) it's hidden, so if I'm inexperienced and non-technical, I don't even
> know where my programs are;
Yes this is a fairly common question. TransGaming put a
~/Transgaming_Drive symlink in the home dir.
Proposal: patch wineprefixcreate to build "~/Virtual C Drive" as the
users fake windows tree (notice the lack of ugly underscores)? Cons:
- Some users may not like it (really there's not much useful stuff in
there except the program EXEs)
- Are there issues with spaces in the paths used for these drives? I
don't think we want to have underscores here
- Localization: do we really want to translate "Virtual C Drive" into a
bazillion languages? If so is the support hassle of having everybodies C
drive in a different place worth it? OTOH you can say "the C drive is
always in ~/.wine/dosdevices/c:/*" and be done with it.
> 2) there is no reason I should have to "blow away" my data just because
> I have to blow away the config. Reinstalling a program over itself is
> far far easier than reinstalling it from scratch, and that doesn't even
> cover the pure data that might be in "C:\My Documents".
Well by "config" we mean:
* Drive mappings
* Config file, or what's left of it :)
In future the config file will disappear and you'll only have the
registry. The problem is we don't have a good way to upgrade it.
Currently once the users .wine is created their registry is "static" and
even if we improve the default registry it'll never be recreated. Ditto
for COM registrations, they are only done at wineprefixcreate time as well.
This comes back to the discussions me, Dimi and Alexandre were having a
So for now the easiest way to make sure you're up to date is just to
reinstall stuff because if you delete the registry, you also lose app
settings and quite a few programs don't like their registry trees
> And I don't see why we don't gently educate the users in the importance
> of this issue (as a dedicated dialog would certainly do), but instead
> just let them keep on doing things the same old crummy Windows way, as
> if it was ever a good idea.
Many users don't read info/error dialogs especially when technical,
likewise Wine has to be auto-configuring. Not only is it required by
most packaging technologies (they don't allow user interaction, often by
design) but if we want Wine to ever stabilise and become a part of most
distros base sets again it has to involve zero user interaction to setup.
More information about the wine-devel