configuring wine

Alex Pasadyn ajp at mail.utexas.edu
Mon Oct 13 15:20:23 CDT 2003


After taking a look at winesetuptk, I have some questions:

I've been watching the IRC channel and I've seen a lot of people who 
install wine first (either from a binary package or from "make install") 
and then ask how to configure it.  They want a single command they can 
run to simply get things to a reasonable state.  While tools/wineinstall 
generally does this it's not quite what they are looking for.

I think there are two separate problems that are being addressed, and it 
makes sense to have and document two stages of configuration.  Step one 
doesn't ask too many questions (really just whether you want to use an 
existing "C" drive or not) and results in a "working" Wine (with all 
DLLs set to "builtin").  Step two would then use Wine itself to allow 
the user to customize things graphically.

It seems worth it to me to split tools/wineinstall into two parts so 
that the configuration part can be easily run as a separate step 
(possibly with a Tk dialog later on?).  This initial configuration 
_must_not_ depend on a working Wine.  Further, a user might want to run 
it again later if their partitions change, etc.  Does anyone object to 
this change?  (The existing wineinstall could just call the next script 
after compiling and installing Wine.)  Perhaps once winecfg is finished, 
it could be automatically launched after the initial configuration.

As an alternative to this, we could have "make install" and the binary 
packages always create a system-wide fake C drive and install the 
default system-wide config file.  Even though these are read-only, it's 
enough to run winecfg and notepad, and then the real C drive detection, 
etc could be moved into winecfg.  This might be better as the user only 
has one program to run, and they can see that wine "works" right out of 
the box.  It also has the benefit that every user would start from the 
same place at least once.  One of the hardest things about helping 
people troubleshoot now is figuring out how they got to where they are.

Finally, I thought at least one aspect of the interface for winesetuptk 
was more intuitive than winecfg.  The winecfg has one tab where you 
specify whether you are changing global or application-specific 
settings, but winesetuptk repeats that concisely at the top of every 
page using a drop-down list and add/copy/rename/remove buttons.  The way 
winesetuptk does it seems less likely to result in mistakes by users.

Also, winesetuptk includes pictures of the different WineLook and 
windowing mode options, which is a nice touch.  Basically, it'll take a 
fair amount of work to get winecfg up to the "niceness" level that 
winesetuptk currently has (not to mention actually saving the changes). 
  Can we all send patches against the winecfg in CVS or does someone 
have a more up-to-date version?

Alex




More information about the wine-devel mailing list