Bad prefs that I'm planning on dropping
Dimitrie O. Paun
dimi at intelliware.ca
Mon Sep 15 09:55:20 CDT 2003
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.
> * 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
> * 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.
> 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.
More information about the wine-devel