[CCd wine-devel as I think you meant it to go there originally]
Holly Bostick wrote:
Seems to me that whether or not 99% of users will forget is not your
responsibility as developers. Other than making very sure that users
know there is something to remember, further programming against the
poss
I was always a fan of upgrades, but in the meantime I am more a follower of:
"If you upgrade to this new version, please re-setup your whole wine configuration
and merge over your data."
This should only very seldom be the case anyway.
This causes less work for us and less work for the user due to
On Tue, Sep 28, 2004 at 12:46:12PM +0100, Mike Hearn wrote:
> There are a bunch of different ways we may want to upgrade the users
> configuration:
I was always a fan of upgrades, but in the meantime I am more a follower of:
"If you upgrade to this new version, please re-setup your whole wine c
> I'm not sure we should design this system on the assumption that we suck
> and will probably blow things up. I don't know of any other programs
> that use such a mechanism when upgrading!
Well, Service Packs on Windows have the option (on by default) to back up all
changed files just in case M
Mike Hearn wrote:
Wouldn't it be better to do good testing and have, ooh, I don't know,
a beta testing program? In other words, to ensure we *don't* mangle
the users data?
Yep that too.
I'm not sure we should design this system on the assumption that we
suck and will probably blow things up. I
I don't know, better safe than sorry. You are touching users Data here.
they should have an informed choice. A message box, something? maybe
refuse to run, than he will notice.
>
So a first time newbie installs wine and is very happy with it. After
1/2 a year he feels more confident and the new
Mike Hearn wrote:
There is evidence that users don't see or ignore such warnings :(
If you aren't confident that an upgrade won't break stuff you can
always manually back up the wineprefix before running the new version,
I don't think we need to do anything ourselves. Most users won't be
adminis
1. It is more than common to use more than one wine version on the same
prefix. So what will the older version do. is it always future compatible?
Yes, hopefully. There are limits to what we can do here though, I suspect.
2. Please do not silently touch a user's wineprefix. Users are used to
have
Mike Hearn wrote:
There are a bunch of different ways we may want to upgrade the users
configuration:
- Changes to $WINEPREFIX (~/.wine), for example:
- Introducing faked DLL headers
- Improved drive detection
- Changing the way the registry is stored
- Adding stuff to the virtual Win
There are a bunch of different ways we may want to upgrade the users
configuration:
- Changes to $WINEPREFIX (~/.wine), for example:
- Introducing faked DLL headers
- Improved drive detection
- Changing the way the registry is stored
- Adding stuff to the virtual Windows drive
- Modif
--- Mike Hearn <[EMAIL PROTECTED]> a écrit : > On Thu, 2003-09-25 at
20:13, Sylvain Petreolle wrote:
> > Cant work, as 'make install' must be done being root user.
>
> Good point. Possibly a timestamp key in the registry that is updated
> with each alteration of winedefault.reg and is also update
On Thu, 2003-09-25 at 20:13, Sylvain Petreolle wrote:
> Cant work, as 'make install' must be done being root user.
Good point. Possibly a timestamp key in the registry that is updated
with each alteration of winedefault.reg and is also updated in the code.
If they don't match, we print an error (a
Cant work, as 'make install' must be done beeing root user.
> OK, so the best way to tackle this then is probably once we moved the
> config entirely into the registry for packages to remerge the default
> registry on install/upgrade?
>
> Of course people who do "make install" from CVS are a bit
On Thu, 2003-09-25 at 18:21, Alexandre Julliard wrote:
> No, that hardcoded list is only for dlls that we know will never work
> as native. We don't want to have to change it every week depending on
> the progress of some other dll. There are plenty of things that you
> may have to add in the regis
14 matches
Mail list logo
