Summary

This blueprint covers the coming changes needed for proper Wine integration in Karmic.

Release Note

For users who have installed Wine, the Applications->Wine menu has been streamlined. Applications->Wine-Uninstall Wine Applications can now be done directly through Applications->Add/Remove, Applications->Wine->Browse C:\ Drive is now in the Places menu, and Applications->Wine->Configure Wine has been replaced with the new Wine control panel at System->Preferences->Wine Applications

Rationale

Popcon says that about 50% of our users have installed Wine, however it very much feels like it's not a proper part of the desktop. At the same time, it can be difficult to manage expectations about how Wine functions, how likely it is to work, and where applications and data go compared with the rest of the system.

User stories

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

executable-handler

The executable-handler is a new package and will be based on the security team discussions from karmic-blocking-malware. It depends on the icoutils package and both will be installed by default.

Executable-handler contains:

See the karmic-blocking-malware spec for more discussion.

If clamd is running, a scan of a single file will take a very small amount of time and can be done before displaying the dialog. If clamd is not running, it will take about 5 seconds to start up, and will need to be coded for within executable-handler (such as by having a dialog that displays a loading bar). We also need to handle the case where clamd is starting up but isn't yet started when the user opens executable-handler; we can test what happens here.

We will start loading clamav immediately upon double click, however the dialog will open immediately and show a progress bar while loading clamav. The scan will then happen automatically.

Scan for viruses should also be a context menu option for individual files that are already marked executable (eg those on a USB stick).

wine-tahoma-replacement and wine-symbol-replacement

The Wine package will have its Symbol and Tahoma replacement fonts split off into separate packages. These can become part of the default install, as they are free and provide functionality to users who don't run windows applications since they appear in documents and web pages. These fonts will alias to their replacements; users who manually drop the native Windows versions into .fonts should have the real fonts take over without further hassle.

Graphical improvements to these fonts are appreciated and can be committed to Wine upstream; they are not "final" with the appearance of all the glyphs yet (and may still be missing some).

File sizes:

wine-support package

A new package, wine-support, will be recommended by Wine, and will itself recommend clamav. The package contains code and dialogs for a new "System->Preferences->Wine Applications" and Right click .exe->Properties->Wine (a nautilus extension). Here the user can set Wine preferences like default version to emulate and whether to launch in a separate window. If Clam is installed we can also place further controls for clamav and Wine integration.

fuseciopfs package

The "case insensitive on purpose" FUSE module: http://www.brain-dump.org/projects/ciopfs/

Wine can have speed and correctness improvements by forcing the entire ~/.wine folder to be case insensitive. System Shock 2, for instance, takes 30 minutes to load a level on ext3 but only 4 seconds on vfat because proving that 10,000 case-insensitive files do not exist in multiple folders is much more efficient on a case-insensitive file system.

The ~/.wine folder needs to be mounted by ciopfs at session start (or at ~/.wine creation). This is because Wine isn't always running when the user is interacting with the Wine filesystem. Many applications distribute patches as .zip files that are meant to be extracted into their program folder and overwrite some files; often the files in these patches are case-insensitive matches (eg new FOO.DAT is supposed to overwrite Foo.dat), and Wine will necessarily get very confused about which file to use unless there is only one in the filesystem.

Ciopfs is transparent, mounting itself as ~/.wine over the "real" ~/.wine. Wine could detect ciopfs programatically (and thus turn on its optimizations), however. Ciopfs requires write access to the folder being mounted, however this is not generally an issue for most Wine folders - getting Wine to properly use case-insensitive optimizations on a non-writable case-sensitive filesystem remains an upstream issue, however it is currently an uncommon use case since Wine doesn't well support system-wide installations.

Implementation: wine-support package will have a script that will check for and mount all Wine prefixes in the user home folder as ciopfs at session start (usually this will just be ~/.wine). wine-support will recommend fuseciopfs

nautilus

Add a default bookmark for: .wine/dosdevices/c\: -- this will not show up unless Wine is installed. Give it an icon consisting of a folder with a Wine glass emblem similar to the home emblem. Icon is still to be made.

Gnome-App-Install

If Wine applications and the wine-support package are installed, they will appear in a new Wine menu with their normal icons and text explaining that they're Wine applications in the window below.

UI Changes

Code Changes

Migration

Existing .wine folders don't use ciopfs. It is currently untested what happens when you remount them that way; in theory this should just work, however if there are filename conflicts (a state that would already confuse Wine) this may lead to "hidden data" issues. Uninstalling ciopfs should still work in that case.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Design Team Testing

The design team will be working various prototypes of the executable handler and thumbnailer into their weekly user tests. The goal is to discover the appropriate content of the dialog boxes as well as a good standard for the icons.

There is experimental code in wine-support for handling multiple wine prefixes, however presenting this to the user in a sane way will require testing, if it is even to be done at all. For the first implementation, we can simply use the default prefix of ~/.wine -- if that doesn't cover all use cases, then an ability to "unlock" support for multiple prefixes can be added to System->Preferences->Windows Applications

Unresolved issues

If/when Gnome-App-Install is replaced by the new App Center, we'll need to put Wine functionality there too. Most of the code should be portable however (python scripts, generated .desktop files). Gnome-App-Install also requires Wine to be installed in order to properly remove Wine applications. Wine applications also must be removed with their uninstallers (requiring manual clicks); if the user uninstalls Wine but then tries to uninstall the Wine apps they may be surprised that this requires an extra step, or doesn't work if the user is offline and needs to redownload Wine.

Discussion

By design: downloads are not executable (can create issues in combination with wine, since you need to chmod -> that's a good thing). We just need a well defined message that explains why it just fails. The UI therefore is not finalized. Maybe also warn for dependencies that are needed for this file (for example .exe, which could require wine)

Uninstalling windows applications using add/remove will first run the uninstallers of the applications and then wine?

MIME needs to differentiate between self extracting archives and actual setups

wine-config/control: Compatability mode / Wine type mode -> inside GNOME/Nautilus (select which type of OS to emulate). Example: gnome-mount/nautilus-share.

wine c-drive in the places menu. Use bookmarks (if bookmark is faulty, it won't be displayed)

applications 'moved' with migration assistant can't be guaranteed to work. You also risk registry corruption.

Interesting related brainstorming going on at the QA site.

CategorySpec

karmic-wine-integration (last edited 2011-11-05 16:24:15 by 71)