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