karmic-wine-integration

Revision 14 as of 2009-06-07 21:06:36

Clear message

Summary

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

  • wine-support package consisting of a few python libraries for detecting/handling Wine installations
  • a nautilus thumbnailer based on icoutils for showing embedded icons in .exe apps
  • changes to gnome-app-install for uninstalling Wine applications
  • a gnome control panel for wine applications

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

* Downloads steam intentionally, double clicks it, wants it to work * Downloads program unintentionally thinking it a picture, double clicks it, needs to learn about the problem and cancel * Has windows program on a CD, puts it in, wants it to work

Assumptions

Design

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

Implementation

executable-handler (and executable-handler-gnome)

This executable-handler is 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:

  • A new thumbnailer for executables (described in UI changes below)
  • Python scripts that take default MIME type for executables (wine .exe, Java .jar, python, etc)
  • Dialogs presented upon double clicking executables. If clamav is installed, we will automatically scan the file on double click. If the file does not have the executable bit set, we will interrupt the user, notify them of the problem, and notify them of the scan. Different versions of how to do this will be tested by the design team.

See the karmic-blocking-malware spec for more.

wine-tahoma-replacement and wine-symbol-replacement

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

wine-support package

Recommended by Wine, recommends clamav. Contains code and dialogs for System->Preferences->Wine Applications and Right click .exe->Properties->Wine (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.

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

  • Wine package itself:

    • Applications->Wine becomes condensed to what used to be in Applications->Wine->Programs

    • New System->Preferences->Wine after Wine is installed

    • Gnome-App-Install will show Wine apps if they're installed (otherwise remain the same)
    • Browse C:\ Drive link moved to Places
  • Wine-support package (installed by default without Wine, affects all users):
    • Double clicking a .exe will display a new dialog offering to install Wine

  • Nautilus and default icon set: Places->Wine C:\ drive

  • executable-handler
    • .exe applications will have a new icon consisting of their built-in icon embedded into a generic "Windows Program" icon with a Wine logo. This simultaneously tells the user it's a program, it's a wine program, and also what program it is.

Code Changes

  • Gnome-App-Install will be extended by Scott Ritchie.
  • Wine-support will be authored/packaged by Scott Ritchie (already about 75% complete), with some community help already provided
  • thumbnailer is mostly done (icon may change though)
  • wine python module for applications to call Wine functionality (eg Gnome-App-Install), almost done

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

TODO: mention user testing from design team

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.

Unresolved issues

If/when Gnome-App-Install is replaced by 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.

BoF agenda and discussion

Discussion

  • System->Preferences->Wine Applications or Windows Applications?

    • Makes it clear it's Wine (and not, say, Crossover) - icon can do this as can words
    • on the other hand user needs to know about Wine and such (although we are reminding them with the Wine menu and icons and dialogs now).
  • Dialogs need a look-over
    • when user double clicks .exe without Wine
    • when user double clicks .exe with Wine but without u+x permission
  • Wine team (or rather the lack of it)

    • Basically it's just ScottRitchie but there may be no need for a formal "team"

    • Will be removed (currently open team)

  • Not clear what should happen if a user uninstalls Wine while still having Wine applications installed. Should Applications->Wine menu be hidden, should the user be prompted to remove them? We have to have Wine installed in order to remove Wine applications properly (by running their uninstallers), and this can get complicated if someone tries to remove a wine application after Wine is uninstalled.

    • What about different users?
  • ClamD takes a few seconds to start, need to start it before we want to scan new Wine program. Rely on execute bit for clamscan.
  • ClamFS + ciopFS FUSE systems for Wine folder. Example: game starts (20min.) because all case checks, 3secs on cipfs. Case insensitive complete .wine folder (mount goes with the .desktop file)

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?

* icoutils (70kb, thumbnailerscript for GNOME) -> 'nice' icons for "wine" executables -> Include it

  • - check how to do this for dolphin

* Fonts * Information dialog

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.

CategorySpec