Future of .wine/config

"Adrian Willenbücher" addy86-ml at gmx.net
Thu Aug 12 04:59:49 CDT 2004


> We know that, this is why we're:
> 
> a) Eliminating as many config options as possible

Although this increases simplicity, it also narrows the user in his
possiblities to adjust wine to his needs.
To take away configuration options from the user seems to be a trend within
the wine developers' community ;-) Why do you do this? Wine users are Linux
users (although they run Windows applications). They _want_ to be able to
configure their software to the limit (while at the same time being able to
install a package and start working - but this is no contradiction!).

> b) Writing winecfg to configure the rest graphically

In fact I try to do as much work as I can within a terminal. If I have the
(reasonable) choice between GUI and TUI, I choose TUI (and I'm not an old
Linux guru). Why? Well, at first it's cool :-D , but I also hate pushing the
mouse and moving the right hand from keyboard to mouse and back. I don't
know how many other Linux users think similar about this.
What's so bad about having a text file with all options? In other words:
What advantages would a graphical, specialized tool have?
Of course, it simplifies wine's configuration for first-time users, but
think about the disadvantages:
1. It has to be written. While a developer writes winecfg, he could also
hack wine and improve it.
2. It has to maintained. Whenever there is a new option, winecfg has to be
updated.
3. It has to be documented as well as config file has to be documented. So
this is no pro for winecfg.
4. It narrows choices. If the user wants some unusual config, he will have
to edit the registry files manually. This problem already appears at the
very beginning with wineinstall: If I don't want to install wine in
/usr/local but in /home/addy/wine (because wine changes so often that it's
easier and more secure not to have to be root every time I update it), I
have to edit wineinstall. (wineinstall is just an example of the overall
trend)

There's no problem (from user's point of view) about a config file
coexisting with a graphical tool editing this file.

> > 2. Although it might be convenient to access both, wine's and the
> Windows
> > programs' data, using the same functions, this should not be done as
> there
> > should be a clear distinction between wine and the programs it runs.
> 
> You realise that the config file was already mounted into the registry 
> on startup right? This is just about moving files around really.

That's not the point. Wine's configuration should not be mixed with Windows
programs' configuration, because the one is wine and the other ones are the
programs which are run by wine. Wine is _not_ another Windows application so
its data has nothing to do in the registry. The only reason why wine
implements the principle of the registry should be that Windows applications
use it, but not wine. Reason:
> > 4. To put wine's configuration into the registry is a step towards a
> > "Wine-is-Windows", i.e. not just providing Windows' functionality but
also
> > behaving like Windows (and this should be avoided under all
circumstances
> > ;-) ). Wine is "just" an emulator for Windows, it is not supposed to be
a
> > new "Open Source Windows".
> > The Windows' handling of configuration data (every application puts its
data
> > into the same two files: the registry) is inferior compared to the Unix'
> > one's (every application has its own configuration file/directory in a
> > common place). This makes it difficult e.g. to manually deinstall a
> > program/software package.

> It has 
> one BIG advantage also, namely that we can write a graphical editor for 
> it! It's really hard to do that with the current config file even though 
> they have the same syntax.

Why (just curious)?

> > 3. If a program misbehaves and messes up your registry and/or if you
> decide
> > to start again with a clean installation, you just delete some registry
> > files and directories and have a new system (I think of the case you
> don't
> > work in a native Windows installation) without to setup wine's
> configuration
> > again.
> >
> > 4. To put wine's configuration into the registry is a step towards a
> > "Wine-is-Windows", i.e. not just providing Windows' functionality but
> also
> > behaving like Windows (and this should be avoided under all
> circumstances
> > ;-) ). Wine is "just" an emulator for Windows, it is not supposed to be
> a
> > new "Open Source Windows".
> > The Windows' handling of configuration data (every application puts its
> data
> > into the same two files: the registry) is inferior compared to the Unix'
> > one's (every application has its own configuration file/directory in a
> > common place). This makes it difficult e.g. to manually deinstall a
> > program/software package.
> 
> > Well, my opinion. What do you think about it?
> 
> I think you need to open up ~/.wine/system.reg in a text editor and 
> observe that it has a nearly identical syntax to the config file ;) 
> Exporting a configuration is just a matter of copy/paste.

First you have to find all places containing wine's configuration. Then you
have to copy/paste all those pieces and hope you didn't forget one ;-).

> Importing becomes "regedit myconfig.reg".

So you have to start wine in order to setup the configuration in order to
start wine. Do you think this is a good way?


Adrian

-- 
NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl




More information about the wine-devel mailing list