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