Surely the Gnome/KDE menu item could also use the Start Program menu, and
provide a sub-menu so that installing a Windows program using a Windows
installer automatically added a menu item in the same way that Windows
does.
Jeremy White <[EMAIL PROTECTED]> on 26-10-2000 05:25:20 PM
To: [EMAIL PROTECTED]
cc: (bcc: David Goodenough/DGA/GB)
Subject: Wine packaging - part 2 - what RPM/DEBs do
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
