Superseded by: WineIntegration
Launchpad Entry: https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-wine-integration
Created: May 15, 2009
Contributors: ScottRitchie, Christian Dannie Storgaard (Cybolic), AndyPiper
Packages affected: wine, gnome-app-install, nautilus
New packages: executable-handler, wine-support, ttf-tahoma-replacement, ttf-symbol-replacement, fuseciopfs
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
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
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.
- A user downloads a Windows program installer intentionally, double clicks it, and wants it to work
- A user downloads a program unintentionally thinking it a picture, double clicks it, needs to learn about the problem and cancel
- A user has a windows program on a CD, puts it in, wants it to work
You can have subsections that better describe specific parts of the issue.
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.
- A new thumbnailer for executables (described in UI changes below)
- Python scripts that take default MIME type for executables (wine .exe, Java .jar, python .py, etc)
- Scripts similar to gnome-codec-install for installing Wine when opening .exe
- 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 show the virus scan. Different versions of how to do this will be tested by the design team.
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).
- Symbol: 25.4 KB
- Tahoma: 87.0 KB
- Tahomabd: 78.5 KB
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.
A fully working implementation of the idea is implemented in the packages wine-preferences and nautilus-wine available from my PPA at https://launchpad.net/~cybolic/+archive/ppa/ . No integration with Clam is done yet. The executable-handler code that I've also written does however integrate with Clam but the code is not packaged yet. -- Christian Dannie Storgaard
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
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.
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.
- 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
- Isn't this supposed to be handled by the executable-handler package? -- Christian Dannie Storgaard
- Double clicking a .exe will display a new dialog offering to install Wine
Nautilus and default icon set: Places->Wine C:\ drive
- .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.
- 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
A complete implementation done by me in cooperation with Scott Ritchie is already available at https://launchpad.net/~cybolic/+archive/ppa/ -- Christian Dannie Storgaard
- thumbnailer is mostly done (icon may change though)
- wine python module for applications to call Wine functionality (eg Gnome-App-Install), almost done
- It should actually be complete and is available in the package python-wine available from my PPA listed above. -- Christian Dannie Storgaard
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.
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
- wine-preferences already includes multiple wine prefix handling, available by running the program with the --enable-bottles switch. -- Christian Dannie Storgaard
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.
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
- Information dialog
any thoughts about including winetricks (which itself depends on cabextract?) - this already has a GTK GUI available and quickly enables tweaks to be made and Windows components to be installed
- any thoughts about making the default Wine theme match the Ubuntu GTK defaults and fonts?
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.
karmic-wine-integration (last edited 2011-11-05 16:24:15 by 71)