BetterIntegratedWineSpec

Revision 12 as of 2006-03-18 20:04:02

Clear message

Summary

A more integrated, intuitive, and functional environment for running Windows applications via the Wine package is essential to acheiving a true competitor to Windows. We need to do some things to help things along for the user.

Rationale

There is currently no easy way to install or use Windows applications, configure Wine, or exlpore the virtual Windows environment (C: drive), nor is there an easy way to port Windows programs to Ubuntu packages suitable for Universe.

Use cases

  • Joe Gamer wishes to switch to Ubuntu because he heard that he can run his latest games in it and it is faster and easier to use than Windows. To run Wine currently, however, he has to open most things through a terminal window and read several howtos on Google.
  • Andy AMD-64 wishes to run Wine. Currently, he has to install a 32-bit chroot environment in a process that is neither easy nor simple, and simply using the 32-bit Wine package won't work.
  • Dan Developer hears that his open source Windows program works perfectly in Ubuntu under Wine, and wishes to support it more formally by creating a .deb package that depends on Wine, builds with winelib, and works on all Ubuntu-supported archs.
  • Paul PPC wants to run a package that is actually a Windows program ported with Winelib. His version of the Wine package, however, can only run Winelib compiled packages, so the Wine package should make it clear that Wine is not an emulator by hiding the binary-loader features present in the i386 and AMD-64 packages.

  • Irene the ISV learns that her third party software can run successfully if compiled with winelib, but doesn't have any means of providing an easy install for users of any arch like she would with [ThirdPartyPackages].

  • Fanny the Fontless installs Steam with Wine, but discovers that none of the text in the program renders. Currently, she has to find a copy of the Tahoma font from somewhere and install it by hand to get a usable program.
  • Mike multiplatform prefers to use a Windows program to do some task but native programs to do others. However, when he does things such as click web or email links in a Windows app, Wine doesn't know to launch his native Linux program unless he hand-configures Wine's registry.

Scope

This specification covers both the Wine package as well as things we can do at the system level to make things easier on the Wine user. This specification covers a Wine package designed for the desktop: a stripped-down Wine without X designed for use on servers that can be run headlessly remains a possible future package.

Design

Nautilus and Gnome

The user will be able to install Wine easily by selecting "Windows Compatibility Layer" from the add applications applet. Once done, this will create a new program group in the applications menu necessary for using Wine and its related applications.

Double-clicking Windows executables in Nautilus will launch them with Wine, and that this is occuring will be made clear by giving them a special Wine icon. If the user doesn't have Wine installed and attempts to run such an executable, they should be alerted to this fact and prompted if they want to install Wine (if possible) in much the same way a user is prompted to install Samba or NFS if they launch the shared folders applet without them.

Items placed in the Wine systray will sit alongside other items in Gnome's systray, such as the volume control and update manager. This currently doesn't happen due to a bug upstream, and will likely be fixed without special effort on our part by using the latest Gnome.

The Windows Program Group

Once installed, the user can then select Applications->Windows->Program Files, where his virtual Windows start menu will reside, as well as Applications->Windows->Configure Wine, which will launch winecfg. Links to Wine's included utilities can be placed here as well, the program uninstaller ("Uninstall Windows Programs"), wineboot ("Simulate Windows Reboot"), the registry editor ("Registry Editor"), and even notepad ("Notepad").

Not all of these should be visible by default (particularly the registry editor and notepad), and we should probably get them visible/not visibile by modifying Winecfg.

Fonts

Make a dependency on a virtual windows-fonts package, that can be provided by the existing nonfree msttcorefonts package as well as a new free package consisting simply of aliases for the nonfree Microsoft fonts using free ones. This will allow Wine to at least render readable text when a program (such as Steam) calls for a font such as Tahoma which normally exists on all Microsoft systems but cannot exist in Ubuntu unless first copied by the user. Since Wine will default to using fonts in its own virtual drive (and X should default to real fonts in place of aliases), adding a real version of Tahoma into the Wine folder or fonts folder should still work just as it does now.

Documentation

Wine's documentation is kept seperately upstream, and needs to be merged into the main package. Wine's documentation is currently in obsolete SGML format, unsuitable for use with Scrollkeeper and the Gnome help menu, so it must be ported to XML with a proper .omf file being made - these changes can easily be passed upstream.

Native application integration

See this Wine Weekly News article: http://winehq.org/?issue=307#Launching%20Native%20Apps

There are some "fun projects" Wine has that may be necessary for proper desktop integration here: http://www.winehq.com/site/fun_projects

We may need to create new freedesktop.org standards - for example, currently there is no smooth way to tell the system to launch a particular link in the preferred browser that works across all desktop environments. There's a separate Gnome command, a separate KDE command, and currently Wine does its own hackish thing by simply guessing web browsers.

This link should be helpful: http://wiki.jswindle.com/index.php/Advanced_Wine_User_Information#Runing_Linux_software_From_Wine

Winetools

Winetools should not be used. Or, more specifically, anything that it helps people do should be incorporated into the Wine package itself or a script like Automatix.

Implementation

Development of Wine itself is progressing very rapidly. While it's hard to say this far out, it seems quite feasible to get another stable release done in time for Dapper+1, right around the time the next version of Gnome becomes finished.

Outstanding issues

Some of these issues may be better resolved by moving Wine into main and supported for Dapper +1. This is a huge step, however the Wine project has helped things along significantly by showing openness to another stable release once certain goals are met - if we do this right, another very stable release (1.0) should be out about a month before Dapper+1. That version should also be buildable smoothly on 64-bit architectures, which Wine currently is not.

BoF agenda and discussion

CategorySpec