Okay, part two is to discuss what an RPM or DEB installation
process looks like to the end user.
After some discussion, this is the end user experience
we propose:
1. Installing the package should, IOHO:
A. Install the files to the appropriate place
(/usr/bin? /usr[/share]/doc /usr/lib/wine)
B. Modify ld.conf to include the lib directory
C. [Controversial] Modify Gnome/KDE file associations
to associate .exe files with wine
D. [Controversial] Install a kernel patch to
allow .exe files to be launched from the command line.
E. [Controversial] Do *not* install a /etc/wine.conf
file. IMHO, since the global wine configuration
is IMHO misleading, we shouldn't install one by
default.
F. [Controversial] Create a global KDE/Gnome menu
entry for Wine, put Winecfg under it, and maybe
also put in a simple Windows application launcher.
Hmmm. This could be cool; we could make a little
launcher with checkboxes that turn on good
debug info, and facilitate the creation of a
decent bug report. Also, the wine launcher
could control (hide) the stdout/stderr of
Wine, and give the user an option to see it
if/when Wine crashes. Thus, the wine launcher
would be the thing tied to the .exe associations.
G. [Optional, not a good idea IMHO] Run Winecfg.
H. Print a message telling them what to do next
They should be instructed to install the package as
root, and then exit, just as you normally do for
package installation.
2. As a regular user, they will have several choices:
A. They can run winecfg directly; it will create
their ~/.wine directory, and create their
~/.wine/config and registry files.
B. They can find a .exe with their Gnome or KDE
file manager, and double click on it to start Wine
C. [Okay, now I'm pushing my luck] They can find their
.exe in an xterm, and type 'foo.exe' to have it
auto launch.
D. The old fashioned approach: Run wine from the console
3. When Wine is run for the first time, and doesn't find
a ~/.wine/config file, it will:
A. Check for a /etc/wine.conf config entry along the
lines of 'app_to_run_when_no_winerc', and launch
that app (presumably winecfg).
B. Winecfg would populate ~/.wine correctly.
C. [Controversial] IMHO, there should be no global
/etc/wine.conf file, and the 'app_to_run_when_no_winerc'
setting should be set to winecfg by default.
Now, there are a some things that we have *not*
addressed in this proposal. We haven't tried
to realistically address multi user installations,
or provide for shared registry files. IOHO, that's
best left for Wine 1.1.
There is a lot of good work that is done in wineinstall,
and it should be merged into this process.
Anything else?
Thoughts/Comments?
Jer
