OK, so here is a basic list of settings that I can't be bothered doing UI for in winecfg.
Before I start, I think I should make one thing clear - ultimately I believe winecfg should be removed entirely. Looking at the settings in the wine configuration really rams home how many simply should not be configurable by the user at all.
Back during the 90s when the only people using Wine were happy and comfortable with computers, it was A-OK to have settings like "Use XSHM extension" and assume the users knew what it meant, or if they didn't, that they wouldn't fiddle with it to see what it did.
But, Linux is changing, and we can't assume that sort of thing anymore. Worse, a lot of these settings could simply be autodetected, or are so obscure that the defaults would always suffice (we can auto detect the presence of XSHM, so why would you need to disable it?).
Unfortunately, writing auto detect code is quite hard, a bit boring etc, so for now that'd have to be a long term project. Ultimately there's no reason why Wine should have to be configured at all - in the ideal world it would just get on with it, and the user doesn't have to think about it, maybe they don't even have to know what Wine is, in much the same way that users don't have to know what glibc or XFree is in order to use the latest distros.
So, here's a quick hit list for now:
[x11drv] * XSHM - can be autodetected, 99.9% of Wines users use XFree, which supports it.
* Use DGA - enabling it apparently breaks wines keyboard input, rendering most games useless (and it's usually used for games). Difficult to know when to enable it short of trying.
* Perfect Graphics - controls the use of optimized raster ops. What difference it makes in practice appears to be unknown.
* Allocated system colors - in fact we still have UI for this in the latest version of the code, but I'm not sure what it's for, or what the best value is, I chose a default of 100 because that is what I happened to have in my config file
* Private Color Map - the description for this setting is not helpful, "Use a private color map". I have no idea what this does, or what effect it'd have, so end users are probably just as clueless.
* Synchronous mode - would this be better implemented as a command line switch? For most people who cannot debug problems in the Wine x11drv, it would just slow things down for no apparent reason. For those who can, it's easy to tell people to run wine with the --sync option, for instance, or do "export WINE_SYNCHRONOUS=1"
* TextCP - description is "Code page used for captions in managed mode", which is fine, the problem is that there are no pointers to available codes and what they mean, other than zero meaning ANSI. Why can't this be auto detected? How do we explain how to set it?
* XVideoPort - wow, this one is obscure. What is a video port when it's at home? Isn't that something X should take care of?
* Use XRender/antialias control - this stuff should be controlled by fontconfig, there's no need to dupe settings here.
[registry] All of them. The defaults seem sane enough:
;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Where to find the global registries ;"GlobalRegistryDir" = "/etc"; ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Registry periodic save timeout in seconds ; "PeriodicSave" = "600" ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y"
Is there ever a reason why a user would want to change these? The last one in particular seems rather arcane - why would anybody want Wine to flush unchanged keys? Some of the global vs home stuff might be useful for administrators or packagers, but they should be OK with using a premade registry file and merging it in.
[TweakLayout] I played around with these when I first started using Wine, and couldn't really figure out what they changed. Does this affect app compatability? Why would a user not want the latest layout?
[Clipboard]
From the names it's only vaguely clear what they do - the defaults have
always worked well for me, can anybody provide good use cases for when they need to be altered?
That leaves the following things as user configurable, though really they probably shouldn't be one day:
* Drive setup - I want to write some autodetect code for this, but I doubt people will want to have always autodetected anytime soon.
* DSound - I can't understand any of these settings, but apparently they can't be easily autodetected???
* Ports setup - I don't know anything about these. They feel like we should be able to autodetect them, but I don't know how.
* Debug - obviously, this has to be set by a human. But is a gui the best place? Perhaps have a switch to winecfg that enables the tab for "developer mode"?
* Windows version. Well, real Windows users don't get to choose this :) Unfortunately while Wine is still imperfect, sometimes altering this can make things come good, so it's optional only in theory.
* DLL overrides - ditto. Smarter defaults can't hurt here, for instance we have MSI only as stubs but we default to them anyway, which is dumb. As it is, some programs that saw the lack of MSI before and offered to helpfully install it, now crash :(
* Desktop/managed mode. Well, desktop mode is maybe a pref for strange people (*cough*lionel*cough* ;), and managed mode is something that still must be sometimes tweaked for each app. Long term this could probably be made automatic so the user can just stick with managed/no-desktop by default and we select the right one as needed.
I've probably missed some. Also, you may feel that a setting I marked as unnecessary, may actually be needed. If so, please tell me why *with reasoned arguments*, not just "well I happen to like tweaking that" or "application X needs it to be set". If a whole load of applications need it to be tweaked one way or the other then maybe, but really that's a bug and we should fix it....
thanks -mike
Le lun 15/09/2003 à 08:58, Mike Hearn a écrit :
- Allocated system colors - in fact we still have UI for this in the
latest version of the code, but I'm not sure what it's for, or what the best value is, I chose a default of 100 because that is what I happened to have in my config file
- Private Color Map - the description for this setting is not helpful,
"Use a private color map". I have no idea what this does, or what effect it'd have, so end users are probably just as clueless.
Those two are for X with less than 15 bits for colors (usually 8 bits).
The first one tells Wine to use Y colors from the system (IE, colors which are the same from app to app). After that number is exhausted, I'm not sure if Wine tries to do a "best fit" between the asked color and the available ones.
The second one tells Wine to define a private color map. Visually, this will cause the colors on the screen to change depending on which application is at the foreground. Colors in non-foreground apps will appear messed-up, because the colormap used (8bits->actual RGB value for the screen) are different from app to app.
I guess not much people use X with 8bits depth nowadays, but I'm not sure it's a reason to drop those two configuration keys.
Vincent
But, Linux is changing, and we can't assume that sort of thing anymore. Worse, a lot of these settings could simply be autodetected, or are so obscure that the defaults would always suffice (we can auto detect the presence of XSHM, so why would you need to disable it?).
Historically, XShm had some bugs on some X servers (like complete freeze of the X server). Something pretty hard to detect at run-time. I doubt that anyone still uses a buggy server like that now though ... This is why ...
- XSHM - can be autodetected, 99.9% of Wines users use XFree, which
supports it.
It has been suppressed since at least one month :-)
- Use DGA - enabling it apparently breaks wines keyboard input,
rendering most games useless (and it's usually used for games). Difficult to know when to enable it short of trying.
- Synchronous mode - would this be better implemented as a command line
switch? For most people who cannot debug problems in the Wine x11drv, it would just slow things down for no apparent reason. For those who can, it's easy to tell people to run wine with the --sync option, for instance, or do "export WINE_SYNCHRONOUS=1"
Well, command line switches should not be DLL dependant... Or do you want to write the 'wine wrapper' that changes cmd line arguments into configuration keys ?
Anyway, this option is clearly not something that winecfg should show to the user. It's a debugging help and we can explain to the users how to change it when they get the error without requiring an UI.
- XVideoPort - wow, this one is obscure. What is a video port when it's
at home? Isn't that something X should take care of?
This will be re-used once we re-add the Xv support to Wine. Basically, if you have multiple graphic boards, you can have multiple Xv adaptators (on my X server, I have two : one for my main board and one for my TV card). This option is here in case Wine does not auto-detect properly the right card and needs some help.
- Use XRender/antialias control - this stuff should be controlled by
fontconfig, there's no need to dupe settings here.
Well, best to wait for the fontconfig stuff to be merged to check if then it's still needed or not.
unnecessary, may actually be needed. If so, please tell me why *with reasoned arguments*, not just "well I happen to like tweaking that" or "application X needs it to be set". If a whole load of applications need it to be tweaked one way or the other then maybe, but really that's a bug and we should fix it....
As said, there is a big difference between a useless option and one that is visible easily by the user.
Lionel
On 15 Sep 2003, Mike Hearn wrote:
But, Linux is changing, and we can't assume that sort of thing anymore. Worse, a lot of these settings could simply be autodetected, or are so obscure that the defaults would always suffice (we can auto detect the presence of XSHM, so why would you need to disable it?).
I can not agree with you more. BTW, thanks for the list, I'll get off my ass and compile the list of parameters, sorry for being lazy.
[x11drv]
- XSHM - can be autodetected, 99.9% of Wines users use XFree, which
supports it.
Moreover, only developers need to disable it, they can use rededit/vi/etc.
- Use DGA - enabling it apparently breaks wines keyboard input,
rendering most games useless (and it's usually used for games). Difficult to know when to enable it short of trying.
True, but wouldn't that make it a good candidate for winecfg, if it needs a lot of changing. Not that I want it there, mind you, I wouldn't know what to do about it! :)
- Allocated system colors - in fact we still have UI for this in the
latest version of the code, but I'm not sure what it's for, or what the best value is, I chose a default of 100 because that is what I happened to have in my config file
- Private Color Map - the description for this setting is not helpful,
"Use a private color map". I have no idea what this does, or what effect it'd have, so end users are probably just as clueless.
These are for 8-bit pallete output, a thing of the past. Those that need changing them (anyone still around using the darn things???) can use regedit.
- Synchronous mode - would this be better implemented as a command line
switch? For most people who cannot debug problems in the Wine x11drv, it would just slow things down for no apparent reason. For those who can, it's easy to tell people to run wine with the --sync option, for instance, or do "export WINE_SYNCHRONOUS=1"
Or regedit/vi/emacs -- it's intended for developers, anyway.
[TweakLayout] I played around with these when I first started using Wine, and couldn't really figure out what they changed. Does this affect app compatability? Why would a user not want the latest layout?
Well, these are for L&F, which is a subjective thing. I don't care much for them, but I guess they are a good candidate for winecfg, as they reflect such a subjective preference.
That leaves the following things as user configurable, though really they probably shouldn't be one day:
- Drive setup - I want to write some autodetect code for this, but I
doubt people will want to have always autodetected anytime soon.
- DSound - I can't understand any of these settings, but apparently they
can't be easily autodetected???
- Ports setup - I don't know anything about these. They feel like we
should be able to autodetect them, but I don't know how.
We should be able to parse something in /proc or somesuch?
- Debug - obviously, this has to be set by a human. But is a gui the
best place? Perhaps have a switch to winecfg that enables the tab for "developer mode"?
What a hell is thing doing? Can't developers tweak it manually? I would not include it in winecfg ATM.
- Windows version. Well, real Windows users don't get to choose this :)
Unfortunately while Wine is still imperfect, sometimes altering this can make things come good, so it's optional only in theory.
This should be settable per application. Some are more happy with a particular version.
- DLL overrides - ditto. Smarter defaults can't hurt here, for instance
we have MSI only as stubs but we default to them anyway, which is dumb. As it is, some programs that saw the lack of MSI before and offered to helpfully install it, now crash :(
These are settable per application already, right?
- Desktop/managed mode. Well, desktop mode is maybe a pref for strange
people (*cough*lionel*cough* ;), and managed mode is something that still must be sometimes tweaked for each app. Long term this could probably be made automatic so the user can just stick with managed/no-desktop by default and we select the right one as needed.
Eventually, desktop should turn into a standalone app (like winedgb). I'm not sure if this is doable right now, but personally I'd like to be able to get rid of this setting. In fact, I think the plan is to fix the managed mode enough for 0.9 so that we no longer _need_ the desktop more, in which case we should not need UI for it -- tweaking it directly in regedit should be enough. I wouldn't include it.
-
Dimitrie O. Paun -
Lionel Ulmer -
Mike Hearn -
Vincent Béron