Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/foo

• Created: Date(2005-12-04T01:43:27Z) by ScottRitchie

• Contributors: ScottRitchie

• Packages affected: wine, wine-dev, msttcorefonts, winetools

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.

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. 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.

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.

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.

Winetools

The winetools program, which remains useful for installing third-party programs such as Internet Explorer, can have a launcher placed in the new Windows program group. Winetools itself can also be cleaned up significantly, as it is somewhat of an ugly program, however this is beyond the scope of this spec.

Implementation

Not much yet.

Outstanding issues

Some of these issues may be better resolved by moving Wine into main and supported. This is a huge step, however the Wine project has helped things along significantly by moving to a stable release cycle. Such a move will likely be differed to Dapper +1 in any case, by which time we will also likely have Wine 1.0 available and buildable on AMD64.

BoF agenda and discussion

CategorySpec