Integrate Wine into Software Center

Currently, Windows/Wine programs lack integration into the system. Since it is being used by a considerable number of people, we should look into integrating it in Software Center, and optionally in other parts of the desktop.

Related branches

Related bugs

Sprints

Whiteboard

Session already in progress, missing some notes from beginning where Scott Ritchie articulated concepts of potential uses
* Issues to consider:
- Wine has support for "prefixes" that act as separate Wine installations (virtual Windows C: drives) in the user folder. The default one is ~/.wine
- These prefixes linger after removing Wine, much like your high scores for frozen bubble (in ~/.frozenbubble) after you remove it. This is more noticeable with Wine because 1) the installed apps can take up considerable disk space, and 2) due to a bug they linger in the "start menu"
- We currently don't have a standard way for knowing which Wine prefixes are even on a system, however this will probably change as of Wineconf (in November)
- The most likely way for a packaged Wine application (see below) to work is to create its own prefix for itself in the user folder, and then copy/symlink a system-wide template. This too would linger after removing that application.

* Concerns about libraries only being used on MS Systems due to licensing issues (MS Win 7 has a "Wine clause" where it can't run on any non-Windows systems
* Who would this benefit? (Windows users own a piece of software, Windows software publishers, etc.)
* Some publishers won't port but it will run in Wine (UTorrent, MicroTorrent, Picasa, etc.)
* Risks are the same as shipping any proprietary, binary software (Wine powered)
* Would upstreams who wanted to do this bundle their own Wine with the package? (Yes, probably. Google did this with Picasa. Scott feels if Ubuntu continues using the stable Wine branch the publishers would have no reason to package their own)
* Is this something we should encourage? (There are 100,000 Windows applications)
* This is another example of where allowing many apps using their own frameworks makes it harder to do more interesting things in the platform so we'd be reluctant to ever recommend this as the way to get your applications on Ubuntu, but it's clearly a way to get some volume on Ubuntu.
* Games is one area we don't have an equivalent for. (Not there's a substitute.)
* Does Wine support only installing in the System Directory> (Sort of - you could put a Wine prefix and it would make the app run as though it's there)
* Could educate upstream publishers that if they want the software run put it initially into a special folder until the user runs it and then it would be copied to its own directory

What's needed?
* Scott would like to be able to have applications offered in the Software Centre? (Great, we could have supported applications [platinum apps on appdb] in there)
* Direct X Support as a potential benefit?
* Mike Guo likes Wine for being able to use DirectX
* Example of running Genealogy product on Wine on Ubuntu (User wants to use Ubuntu, but wants their one Windows package)
* Checkinstall is fine for using a version from the system it was intended to run on but may not be good for Debian packaging. (Works well for Wine)
* Wine maps things to logical drive or could point to specific place
* Winelib was always the library
* In theory you could take a Windows application and run it on ARM using this to port it. (Wine apps on ARM which is the purpose of the Wine ARM folder)
* There is slow support for a multiuser and 32/64-bit environment but not important today (Windows apps predominantly 32 bit still)
* Maybe use a windicator for the user to notice that he is running a Windows program?
* Nothing today to prevent Wine from making general system calls so finding a way to isolate things to prevent accidental or malicious use.
* Wine supports different prefixes and can isolate an app in each subfolder. (Use case is to run various versions of the same app by running them from various folders)
* We can handle prefixes for packaged cases
* Idea is to be able to show apps that have been installed in the home directory. (Could remove using Software Centre even though they were installed by other means)
* We should promote our own applications when the user is installing a Windows program (for example, if a user wants to install MS Office, we warn him that LibreOffice offers the same functionality)
* In a multi-user case the removing of things may be difficult. (Compounded by the fact that you need WINE installed to be able to uninstall the WINE apps.
* Cautious Launcher isn't favored because it's not easily translatable.
* Channel thread that we should encourage local Linux apps rather than enable old Windows addiction ;) (There have been cases where publisher made application work under Wine and by being able to see users they undertook a port to Linux.)
* Adding to the above point, if Canonical notices that a Windows application gets lot of users, Canonical should encourage the application developers to port it to Linux, or even propose to port it themselves.
* If we can make things smoother it will lead to more Ubuntu users.
* We need to be sensitive to GPL redistribution issues (We wouldn't want to run afoul of any licenses)
* Wine can now run .NET 2.5 apps using Mono (Still needs to package)
* From a commercial perspective, could we use this to enable "Windows only" program to get it in the Software Centre. (If it doesn't work in Wine, probably need to contract CodeWeavers to get it working in Wine first.)
* Some unattended installs in Windows are just switches to use InstallShield. (What would be in the package would be the result of having run the install.)
* In the case
* The use case of getting Software Centre to 1) list the applications and 2) remove installed apps, is something that would need to be written.

(Why not other developers? Could be others, but Scott made the comment he'd need to write the code which doesn't exist today.) (ah, sorry then)
* Haven't tried Wine with current built in tools for accessibility
* One other potential use case for packaging that Scott K would be interested in working on would be programming languages still in existence. (16-bit code)