BetterIntegratedWineSpec
Size: 3588
Comment: fonts
|
Size: 21182
Comment: more drafting. Still not done.
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
* '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/foo | * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/better-integrated-wine/ |
Line 4: | Line 4: |
* '''Packages affected''': wine, wine-dev | * '''Packages affected''': wine, wine-dev, msttcorefonts, gnome (for autorun), some other package (for default handling without Wine) |
Line 7: | Line 7: |
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. | We need a good, usable Wine to achieve a true competitor to Windows and solve bug #1. Wine needs a lot of usability improvements at the distribution level. |
Line 10: | Line 10: |
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. | Users want to run Windows apps, but this is currently too difficult in many ways. Users must first learn about Wine, then in many instances run it from the terminal after configuring it by hand. Many programs can be made to work using Wine, however the procedure is often so complex that users simply assume Wine is broken. By integrating Wine better with the Desktop, we both unify the user experience and make things "just work." |
Line 13: | Line 13: |
* Joe Gamer wishes to switch to Ubuntu because he ehard 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. |
* Joe Gamer wishes to switch to Ubuntu because he heard that it's faster and easier to use than Windows and he can run his latest games in it. To run Wine currently, however, he has to open most things through a terminal window and read several howtos on Google. * 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 * We can also use Wine as a basis to include other potentially very useful packages based on Windows software as part of universe or multiverse. When Wine matures enough to be in main, arbitrary Windows apps could be packaged into the partner repository as a very efficient way of porting to Ubuntu. See, for instance, EmuleViaWine spec. |
Line 21: | Line 18: |
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 both the Wine package as well as things we can do at the system level to make things easier on the Wine user. |
Line 24: | Line 21: |
=== Nautilus and Gnome === The user will be able to install Wine easily by selecting "Wine Windows Compatibility Layer" from Gnome-app-install. Once done, this enables a new program group in the applications menu called "Windows" If the user doesn't have Wine installed and attempts to double click an executable (with or without the execute bit set), they will be notified and asked if they want to install Wine in much the same way a user is prompted to install Samba when they launch the shared folders applet. === The Windows Program Group === Once Wine is installed and the user has installed some Windows applications, the user can then select Applications->Windows, where his virtual Windows start menu will reside. Currently, upstream creates a Programs subfolder (representing Windows Program Files) === System->Preferences->Windows Applications === Here we reimplement only the Wine configuration options we need. * (Pulldown menu): "Default Windows version to emulate when launching Windows applications" * Windows 2000 is currently the upstream default, which works for most apps * (unchecked by default) Automatically launch applications upon inserting a disc * This is where the user can disable autorun by default if he enabled it with the checkbox in the autorun prompt * (radio button default): Allow full screen applications to change the resolution * (radio button alternate): Contain full screen applications in a window when smaller than the desktop * These are the two main use cases of Wine's various Window managing options. The latter might not be fully functional in time for Hardy. * (button) Advanced * Launches winecfg, or a similarly functional GTK application. We can consider removing this when Wine's defaults get good enough, however likely not by Hardy. To reimplement the configuration we need in GTK requires some upstream changes (see [http://wiki.winehq.org/ConsoleConfiguration ConsoleConfiguration] on Wine's wiki. === Wine uninstaller === The Wine uninstaller program can have its functionality integrated into gnome-app-install. We add a "Windows Applications" category on the left for Wine apps, except those installed with packages that aren't on the Wine menu. Note that removing these will not require a password. This requires an upstream change in Wine for it to export metadata about what apps are uninstallable, as well as some new code in gnome-app-install to handle wine uninstalling. We will also need to modify Wine to support the command line. See [http://wiki.winehq.org/ConsoleConfiguration Console Configuration] on Wine's wiki. === Autorun === When a CD with Windows autorun is inserted, the user is presented with a prompt asking if they want to browse the CD or launch the autorun application. If the CD also has music on it, the user is presented with 3 options (browse CD contents, play music, or launch autorun application). If the user does not have Wine installed and chooses to launch the application, he is then presented with the same "You need to install Wine" dialog as if he tried to launch an executable by double clicking. Implemented here: [Autorun] |
|
Line 25: | Line 51: |
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. | Wine comes with several fonts for Windows compatibility. Fonts that are "full featured" (ie, have features like bolding and italics working) will be split out into a wine-fonts package. The rest will remain hidden from the system and internal to Wine. === Theme === Wine's default theme should be set to match the Ubuntu default theme. Currently, Wine doesn't know how to read the Linux theme, so if a user changes his theme then Wine will still look like it did originally unless Wine is also configured. Due to the vast differences between GTK and win32, simply reading and interpreting the system theme directly is likely impossible. We can, however, ship a Windows theme that matches our own and set Wine to use it. See, for instance, [WineHumanTheme]. Unfortunately, Wine's theming support is quite slow at the moment, mostly due to problems with alpha blending. If upstream Wine doesn't support theming properly by UserInterfaceFreeze, then we'll use Wine's default theme but instead change the colors to match. The proper way to change the colors is by making our own .msstyle file. === Documentation === Wine's documentation is kept separately upstream, and needs to be packaged and made a dependency of Wine. 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. === Running Applications === In general, Wine applications will be handled the same as ELF binaries with regard to security. We prevent the possibility of running applications accidentally, however once the user has expressed the intent to run the application by setting the execute bit we launch it with BINFMT. Two different cases occur depending on if we have Wine installed. || How to open exe || Wine installed || Wine not installed || || Double click in nautilus with execute bit set || Run application with BINFMT, it loads Wine || Show a dialog saying that this is an executable and that the user needs Wine to run it, optionally allowing download || || Double click in nautilus with execute bit not set || Show a new dialog saying that "Foo.exe is an application. In order to run it you must first give it permission to execute. (Cancel / Launch Application)" Cancel closes; Launch application chmod u+x's and runs the program. || Show a dialog saying that this is an executable and that the user needs Wine to run it || || By inserting a CD with autorun || Do you want to autorun? || Give the same do you want to autorun box, however if user hits yes then give the requires Wine prompt above|| || By downloading with Firefox || Do nothing, wait for user to double click it on desktop || Do nothing || || Download with Firefox (From the downloads window, clicking open) || Do nothing || Do nothing || || By opening with Evolution || Do nothing || Do nothing || || By running an Applications Menu link || Open with script that sets working directory properly (eg winefix) || Prompt to install Wine (note this is possible if user has removed Wine but left apps) || === On First Run === When Wine is first run, it takes a good amount of time to setup the ~/.wine folder using wineprefixcreate. Here, we should modify upstream Wine to create a D-Bus message saying that wineprefixcreate is running, which Gnome then listens to. When Gnome sees the message, it displays an indicator saying "Please wait while your fake Windows installation is created. You can access it from the Places menu." This then creates a .desktop entry in Gnome favorites called "Windows C:\ Drive" === Adding applications to the Start Menu === Currently, Wine adds applications to Applications->Wine->Programs, representing Program Files in the Windows start menu. We will simplify this, squishing Programs into the main Wine folder and renaming it "Windows" so we just have Applications->Windows. In the rare event that a Windows application asks for a shortcut to be put above the Program Files folder (this is possible in Windows), we will simply treat it as though it were in the Program Files folder. |
Line 28: | Line 86: |
=== Code === === Data preservation and migration === |
* None yet. Most will be done by ScottRitchie, the Wine maintainer, however some of the gnome-specific changes will require help from Gnome upstream. |
Line 34: | Line 89: |
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. | * Theming support in Wine is still slow * [http://wiki.winehq.org/ConsoleConfiguration Console Configuration] in Wine is not yet implemented * Windows executables can have embedded icons, however we currently do not extract these and display them. For now, we default to the Wine icon, however icoutils could be used to display them. This may be something fairly simple for nautilus to do, and it would in fact be necessary to implement otherwise we will break icon functionality in the Wine Applications menu. * A user with an existing Wine installation will have many .desktop files calling Wine directly in his Applications menu. We should probably leave them alone. |
Line 37: | Line 95: |
* Discuss eight ways to open an executable (with/without Wine): || How to open exe || Wine installed || Wine not installed || || By double clicking in nautilus || ? || Show a dialog saying its an executable and informing the user about Wine || || By inserting a CD with autorun || Do you want to autorun? || Do nothing? Or prompt about Wine? || || By downloading with Firefox || Do nothing for now || Do nothing || || Download with Firefox (Downloads->Right Click open) || Do nothing || Do nothing || || By opening with Evolution || Do nothing || Do nothing || || By running an Applications Menu link || Open with script that sets working directory properly (eg winefix) || ? (note this is possible if user has removed Wine but left apps) || * The same issue applies to msi files. Should `msiexec /i` be considered equivalent to .exe running (this is the default action for double click on Windows) * Fonts * Gnome-app-install * Changes needed to winecfg, wine uninstaller * Right click->Properties * Theming * Wine + Mono integration * Wine + Gecko integration === Result === * We don't ship MIME entires for Wine. * Hit the 90% by covering win32 (not win64) for the moment and only on i386 (for the moment). * Though most all of this works equally well in 64. * Make the .exe experience the same as for ELF binaries. No worse, no better. * Leave all execution to the `binfmtmisc` handler. * Have a MIME handler that can allow the user to `chmod +x`---this could be done for non +x'ed. * Try to pull the Windows .ICO out of the executable. * This can be done with icoutils package * Currently nautilus has a useless "codec not available" message for -x'ed execs. * `.msi` (non-executable package file). Open with `msiexec`. This is not a security issue until the user runs the file * apport equivalent for crashing/failing win32 applications would be nice * Fonts: * Split out good fonts as a separate package * Leave "compatibility" (just enough for run) fake fonts * Have Free Software available win32 software packaged in universe with a dependency on wine as an example for developers to follow (see EmuleViaWine) * Wine Config * Turn winecfg into a backend-front end application so we can have commandline and KDE-based front-ends. * Really winecfg is superflous. * Only use case is select a different version of MS Windows to emulate. * `alternatives` / `PATH` might be better (think multiple python, java, or GCC installs) * Move to System->Preferences->MS Windows * Actual relevant options are: * Emulate version {2k / XP / 98 / 95 ...} * Rootless / Windowed mode (Size width, height) * Browse C:\ drive * Move to Places menu (desktop entry to GNOME favourites?) * Talk to the Gnomies about this * Gecko duplication (for "Fake IE" / HTML widget) * Ask upstream if they can `dlopen()` and use the local Gecko rather than a second copy. (And maybe local mono). * If not, need to modify the source code and build another copy with `mingw32`. * Fix Wine `msiexec` so that menu items links are made to the executable * Investigate `winefix` * Have the wine interpreter check the registry for the working directory for the executable. * Which could also be set/overridden with right-click propeties. * Get the Wine defaults to the best defaults * Move "Wine Uninstall" * Applications->Wine->Programs->Accessories-> (result of any application calling the Menu method) * Move * Top-level Start-menu entries, move across to always be inside "Programs" * "How do I run wine?" * The populated "Notepad" entry solves this and gives users a hint. * First time "creating your .wine" * Have a dialogue progress "Creating your virtual Windows machine". * Upgrades, may have to re-run `wineprefixcreate` * Store a wine stepping in ~/.wine and bump on upgrade. === Automatic install of wine === Nautilus and gnome-app-install have some magic to suggest applications for file-types that it does not know how to handle. gnome-app-install has a database where it searches for applications that can handle this mime-type. Currently this does only work for main,restricted (because of the security support from canonical). To make this happen with wine, either the /etc/gnome-app-install/packages-whitelist or edit the gconf key "/apps/gnome-app-install/mime-whitelist-components" to include "universe". == Old Comments == Warbo: Just a small point, but Applications>Windows>Program Files could merely be Applications>Windows as nothing other than programs should be in the "applications" menu. Preferences and configs should be in the System>Preferences menu. Also, once WINE has matured a little and perhaps has some GTK/QT wrappers for it's interface there should be nothing wrong with seeing WINE as a legitimate platform for creating programs, just like Mono is now. Therefore, eMule would no longer be in Applications>Windows>(maybe "Internet submenu?)>eMule, it would just be in Applications>Internet>eMule. I think it is important to remove the distinction between FLOSS Linux programs and FLOSS Windows programs to keep the menus managable for novice users. There may be outcry at this integration of Windows programs in Ubuntu, but I see it as "the user's programs" rather than "Windows programs", and it increases the choice available. People may say that Windows programs are badly made, but if that is the case then users will begin to recognise this and perhaps use XMMS instead of WinAMP (I know it is not Free, but I don't know of that many Free music players for Windows) but they will still be able to use their specialised Windows software which has no Linux alternative. The vast number of Windows applications means that they cannot be ignored. As long as only FLOSS programs are put into Universe then the moral arguments are gone and Windows users are left with no "my programs won't work" excuses for not using Ubuntu. To really make this possible WINE needs to transparently create packages of anything being installed through "Install Shield", etc. to allow proper integration with the system and, most importantly, making it very easy to remove software completely later, (this should not be too hard, since WINE runs in a virtual environment allowing complete control over all of it's actions). Ubuntu is currently a far better system than Windows, and must not be brought down in order to appease new converts, but instead Ubuntu should be extended through WINE without giving up it's principles of freedom. That would make it a far better alternative to current Windows users, who may not "get" Ubuntu's philosophy but who can still be converted due to price and performance. Also, integrating Qemu bin-fmt support would allow this integration of WINE for most platforms (x86/amd64, PPC, SPARC, etc) and in the long term, as more and more people leave Windows behind and break the catch-22 of "people use Windows so we develop for Windows. People develop for Windows so we use Windows" then the mainstream hardware market can start to actually invest in newer technologies (I know IBM already do) and then Windows users will finally realise the lack of support they have suffered all these years due to vendor lock-in (only Windows programs will run and only on x86). I know I will get flamed for this, but feel free to offer comments :) Warbo: Here are some relevant points made in the CommunityEdgyIdeas/WindowsCompatibility page: Better wine integration * Add wine programs to the GNOME menu like Xfce or KDE does. * Or make wine create shortcuts like linux programs do. * Wine's C:/ Should be added to the nautilus Places. Since this directory is hidden in the system, it's otherwise hard to browse to. ArtemVakhitov: speaking of fonts, one case should be specifically handled when a user installs a Windows application in Wine whose locale is different from the current one. For example, when I try to install MS Office 2000 Russian edition on C locale, I'm getting unreadable fonts. This can be worked around by prepending wine call with LC_ALL=ru_RU.utf8, but even this for some reason doesn't work reliably in all places. This may be Wine bug, but since there are ways to mitigate it, I thought I would mention this. == New Comments == AzraelNightwalker: * Maybe you could use Wine-Doors in this spec? http://www.wine-doors.org/ * What about Windows viruses? I'm afraid that implementing this spec could make Ubuntu prone to them. ScottRitchie: * Some of Wine doors may be useful by release time, some might not be. We'll have to see where Wine is at that point. Remember that Wine doors is essentially workarounds for applications that can be made to work with Wine but don't install properly yet. As Wine fixes Wine bugs, wine-doors gets less useful (much like how WineTools is useless now). If it's still useful after a few months, at the very least, I'll make a good .deb package of wine-doors and get it into the repository. * We're very aware of the dangers of running viruses. That's why applications don't execute on double click unless the user has either manually marked them as executable or done so through a dialog after being informed that it's a program. This way we stop all accidental viruses except for trojans that the user specifically asks to run - and those we cannot stop unless we completely take away all functionality. KrisMarsh: * I think re-implementing winecfg using GTK would be a bit pointless. Providing there is a Ubuntu-like theme for Wine, we should be ok. Granted, it will be a bit slower to start up - but then we may want to look at optimising it's start up. ScottRitchie: * The idea is to reduce wine configuration from the complicated mess that winecfg is to something that's only a couple of options. Upstream winecfg will always, for instance, have the sound driver selector; we can hide that relatively useless option from the user and just pick a sane Ubuntu default. Since we're redoing it anyway, it might as well be GTK. KrisMarsh: * Providing Wine skinning support is optimised (actually, it's specifically alphablending for small tiled gradients that is slow - we should be able to write a Ubuntu-like theme that works fast enough, regardless of whether the skin slowness is fixed). ScottRitchie: * That's a very good idea, actually. We could just edit the slow parts out of our Windows theme if we have to. KrisMarsh: * How does one help out? :-) ScottRitchie: * Soon (possibly after a week or so) I'll be formalizing the Wine team and making it into a truly collaborative effort. There'll be a nice list of ways to help. You can always, of course, help with Wine upstream ;) ---- CategorySpec |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/better-integrated-wine/
Created: Date(2005-12-04T01:43:27Z) by ScottRitchie
Contributors: ScottRitchie
Packages affected: wine, wine-dev, msttcorefonts, gnome (for autorun), some other package (for default handling without Wine)
Summary
We need a good, usable Wine to achieve a true competitor to Windows and solve bug #1. Wine needs a lot of usability improvements at the distribution level.
Rationale
Users want to run Windows apps, but this is currently too difficult in many ways. Users must first learn about Wine, then in many instances run it from the terminal after configuring it by hand. Many programs can be made to work using Wine, however the procedure is often so complex that users simply assume Wine is broken. By integrating Wine better with the Desktop, we both unify the user experience and make things "just work."
Use cases
- Joe Gamer wishes to switch to Ubuntu because he heard that it's faster and easier to use than Windows and he can run his latest games in it. To run Wine currently, however, he has to open most things through a terminal window and read several howtos on Google.
- 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
We can also use Wine as a basis to include other potentially very useful packages based on Windows software as part of universe or multiverse. When Wine matures enough to be in main, arbitrary Windows apps could be packaged into the partner repository as a very efficient way of porting to Ubuntu. See, for instance, EmuleViaWine spec.
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.
Design
Nautilus and Gnome
The user will be able to install Wine easily by selecting "Wine Windows Compatibility Layer" from Gnome-app-install. Once done, this enables a new program group in the applications menu called "Windows"
If the user doesn't have Wine installed and attempts to double click an executable (with or without the execute bit set), they will be notified and asked if they want to install Wine in much the same way a user is prompted to install Samba when they launch the shared folders applet.
The Windows Program Group
Once Wine is installed and the user has installed some Windows applications, the user can then select Applications->Windows, where his virtual Windows start menu will reside. Currently, upstream creates a Programs subfolder (representing Windows Program Files)
System->Preferences->Windows Applications
Here we reimplement only the Wine configuration options we need.
- (Pulldown menu): "Default Windows version to emulate when launching Windows applications"
- Windows 2000 is currently the upstream default, which works for most apps
- (unchecked by default) Automatically launch applications upon inserting a disc
- This is where the user can disable autorun by default if he enabled it with the checkbox in the autorun prompt
- (radio button default): Allow full screen applications to change the resolution
- (radio button alternate): Contain full screen applications in a window when smaller than the desktop
- These are the two main use cases of Wine's various Window managing options. The latter might not be fully functional in time for Hardy.
- (button) Advanced
Launches winecfg, or a similarly functional GTK application. We can consider removing this when Wine's defaults get good enough, however likely not by Hardy. To reimplement the configuration we need in GTK requires some upstream changes (see [http://wiki.winehq.org/ConsoleConfiguration ConsoleConfiguration] on Wine's wiki.
Wine uninstaller
The Wine uninstaller program can have its functionality integrated into gnome-app-install. We add a "Windows Applications" category on the left for Wine apps, except those installed with packages that aren't on the Wine menu. Note that removing these will not require a password.
This requires an upstream change in Wine for it to export metadata about what apps are uninstallable, as well as some new code in gnome-app-install to handle wine uninstalling. We will also need to modify Wine to support the command line. See [http://wiki.winehq.org/ConsoleConfiguration Console Configuration] on Wine's wiki.
Autorun
When a CD with Windows autorun is inserted, the user is presented with a prompt asking if they want to browse the CD or launch the autorun application. If the CD also has music on it, the user is presented with 3 options (browse CD contents, play music, or launch autorun application). If the user does not have Wine installed and chooses to launch the application, he is then presented with the same "You need to install Wine" dialog as if he tried to launch an executable by double clicking. Implemented here: [Autorun]
Fonts
Wine comes with several fonts for Windows compatibility. Fonts that are "full featured" (ie, have features like bolding and italics working) will be split out into a wine-fonts package. The rest will remain hidden from the system and internal to Wine.
Theme
Wine's default theme should be set to match the Ubuntu default theme. Currently, Wine doesn't know how to read the Linux theme, so if a user changes his theme then Wine will still look like it did originally unless Wine is also configured. Due to the vast differences between GTK and win32, simply reading and interpreting the system theme directly is likely impossible.
We can, however, ship a Windows theme that matches our own and set Wine to use it. See, for instance, [WineHumanTheme].
Unfortunately, Wine's theming support is quite slow at the moment, mostly due to problems with alpha blending. If upstream Wine doesn't support theming properly by UserInterfaceFreeze, then we'll use Wine's default theme but instead change the colors to match. The proper way to change the colors is by making our own .msstyle file.
Documentation
Wine's documentation is kept separately upstream, and needs to be packaged and made a dependency of Wine. 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.
Running Applications
In general, Wine applications will be handled the same as ELF binaries with regard to security. We prevent the possibility of running applications accidentally, however once the user has expressed the intent to run the application by setting the execute bit we launch it with BINFMT.
Two different cases occur depending on if we have Wine installed.
How to open exe |
Wine installed |
Wine not installed |
Double click in nautilus with execute bit set |
Run application with BINFMT, it loads Wine |
Show a dialog saying that this is an executable and that the user needs Wine to run it, optionally allowing download |
Double click in nautilus with execute bit not set |
Show a new dialog saying that "Foo.exe is an application. In order to run it you must first give it permission to execute. (Cancel / Launch Application)" Cancel closes; Launch application chmod u+x's and runs the program. |
Show a dialog saying that this is an executable and that the user needs Wine to run it |
By inserting a CD with autorun |
Do you want to autorun? |
Give the same do you want to autorun box, however if user hits yes then give the requires Wine prompt above |
By downloading with Firefox |
Do nothing, wait for user to double click it on desktop |
Do nothing |
Download with Firefox (From the downloads window, clicking open) |
Do nothing |
Do nothing |
By opening with Evolution |
Do nothing |
Do nothing |
By running an Applications Menu link |
Open with script that sets working directory properly (eg winefix) |
Prompt to install Wine (note this is possible if user has removed Wine but left apps) |
On First Run
When Wine is first run, it takes a good amount of time to setup the ~/.wine folder using wineprefixcreate. Here, we should modify upstream Wine to create a D-Bus message saying that wineprefixcreate is running, which Gnome then listens to. When Gnome sees the message, it displays an indicator saying "Please wait while your fake Windows installation is created. You can access it from the Places menu." This then creates a .desktop entry in Gnome favorites called "Windows C:\ Drive"
Adding applications to the Start Menu
Currently, Wine adds applications to Applications->Wine->Programs, representing Program Files in the Windows start menu.
We will simplify this, squishing Programs into the main Wine folder and renaming it "Windows" so we just have Applications->Windows. In the rare event that a Windows application asks for a shortcut to be put above the Program Files folder (this is possible in Windows), we will simply treat it as though it were in the Program Files folder.
Implementation
None yet. Most will be done by ScottRitchie, the Wine maintainer, however some of the gnome-specific changes will require help from Gnome upstream.
Outstanding issues
- Theming support in Wine is still slow
[http://wiki.winehq.org/ConsoleConfiguration Console Configuration] in Wine is not yet implemented
- Windows executables can have embedded icons, however we currently do not extract these and display them. For now, we default to the Wine icon, however icoutils could be used to display them. This may be something fairly simple for nautilus to do, and it would in fact be necessary to implement otherwise we will break icon functionality in the Wine Applications menu.
- A user with an existing Wine installation will have many .desktop files calling Wine directly in his Applications menu. We should probably leave them alone.
BoF agenda and discussion
- Discuss eight ways to open an executable (with/without Wine):
How to open exe |
Wine installed |
Wine not installed |
By double clicking in nautilus |
? |
Show a dialog saying its an executable and informing the user about Wine |
By inserting a CD with autorun |
Do you want to autorun? |
Do nothing? Or prompt about Wine? |
By downloading with Firefox |
Do nothing for now |
Do nothing |
Download with Firefox (Downloads->Right Click open) |
Do nothing |
Do nothing |
By opening with Evolution |
Do nothing |
Do nothing |
By running an Applications Menu link |
Open with script that sets working directory properly (eg winefix) |
? (note this is possible if user has removed Wine but left apps) |
The same issue applies to msi files. Should msiexec /i be considered equivalent to .exe running (this is the default action for double click on Windows)
- Fonts
- Gnome-app-install
- Changes needed to winecfg, wine uninstaller
Right click->Properties
- Theming
- Wine + Mono integration
- Wine + Gecko integration
Result
- We don't ship MIME entires for Wine.
- Hit the 90% by covering win32 (not win64) for the moment and only on i386 (for the moment).
- Though most all of this works equally well in 64.
- Make the .exe experience the same as for ELF binaries. No worse, no better.
Leave all execution to the binfmtmisc handler.
Have a MIME handler that can allow the user to chmod +x---this could be done for non +x'ed.
- Try to pull the Windows .ICO out of the executable.
- This can be done with icoutils package
- Currently nautilus has a useless "codec not available" message for -x'ed execs.
.msi (non-executable package file). Open with msiexec. This is not a security issue until the user runs the file
- apport equivalent for crashing/failing win32 applications would be nice
- Fonts:
- Split out good fonts as a separate package
- Leave "compatibility" (just enough for run) fake fonts
Have Free Software available win32 software packaged in universe with a dependency on wine as an example for developers to follow (see EmuleViaWine)
- Wine Config
- Turn winecfg into a backend-front end application so we can have commandline and KDE-based front-ends.
- Really winecfg is superflous.
- Only use case is select a different version of MS Windows to emulate.
alternatives / PATH might be better (think multiple python, java, or GCC installs)
Move to System->Preferences->MS Windows
- Actual relevant options are:
- Emulate version {2k / XP / 98 / 95 ...}
- Rootless / Windowed mode (Size width, height)
- Actual relevant options are:
- Browse C:\ drive
- Move to Places menu (desktop entry to GNOME favourites?)
- Talk to the Gnomies about this
- Move to Places menu (desktop entry to GNOME favourites?)
- Gecko duplication (for "Fake IE" / HTML widget)
Ask upstream if they can dlopen() and use the local Gecko rather than a second copy. (And maybe local mono).
If not, need to modify the source code and build another copy with mingw32.
Fix Wine msiexec so that menu items links are made to the executable
Investigate winefix
- Have the wine interpreter check the registry for the working directory for the executable.
- Which could also be set/overridden with right-click propeties.
- Get the Wine defaults to the best defaults
- Move "Wine Uninstall"
Applications->Wine->Programs->Accessories-> (result of any application calling the Menu method)
- Move
- Top-level Start-menu entries, move across to always be inside "Programs"
- "How do I run wine?"
- The populated "Notepad" entry solves this and gives users a hint.
- First time "creating your .wine"
- Have a dialogue progress "Creating your virtual Windows machine".
Upgrades, may have to re-run wineprefixcreate
- Store a wine stepping in ~/.wine and bump on upgrade.
Automatic install of wine
Nautilus and gnome-app-install have some magic to suggest applications for file-types that it does not know how to handle. gnome-app-install has a database where it searches for applications that can handle this mime-type. Currently this does only work for main,restricted (because of the security support from canonical). To make this happen with wine, either the /etc/gnome-app-install/packages-whitelist or edit the gconf key "/apps/gnome-app-install/mime-whitelist-components" to include "universe".
Old Comments
Warbo: Just a small point, but Applications>Windows>Program Files could merely be Applications>Windows as nothing other than programs should be in the "applications" menu. Preferences and configs should be in the System>Preferences menu. Also, once WINE has matured a little and perhaps has some GTK/QT wrappers for it's interface there should be nothing wrong with seeing WINE as a legitimate platform for creating programs, just like Mono is now. Therefore, eMule would no longer be in Applications>Windows>(maybe "Internet submenu?)>eMule, it would just be in Applications>Internet>eMule. I think it is important to remove the distinction between FLOSS Linux programs and FLOSS Windows programs to keep the menus managable for novice users. There may be outcry at this integration of Windows programs in Ubuntu, but I see it as "the user's programs" rather than "Windows programs", and it increases the choice available. People may say that Windows programs are badly made, but if that is the case then users will begin to recognise this and perhaps use XMMS instead of WinAMP (I know it is not Free, but I don't know of that many Free music players for Windows) but they will still be able to use their specialised Windows software which has no Linux alternative. The vast number of Windows applications means that they cannot be ignored. As long as only FLOSS programs are put into Universe then the moral arguments are gone and Windows users are left with no "my programs won't work" excuses for not using Ubuntu. To really make this possible WINE needs to transparently create packages of anything being installed through "Install Shield", etc. to allow proper integration with the system and, most importantly, making it very easy to remove software completely later, (this should not be too hard, since WINE runs in a virtual environment allowing complete control over all of it's actions).
Ubuntu is currently a far better system than Windows, and must not be brought down in order to appease new converts, but instead Ubuntu should be extended through WINE without giving up it's principles of freedom. That would make it a far better alternative to current Windows users, who may not "get" Ubuntu's philosophy but who can still be converted due to price and performance. Also, integrating Qemu bin-fmt support would allow this integration of WINE for most platforms (x86/amd64, PPC, SPARC, etc) and in the long term, as more and more people leave Windows behind and break the catch-22 of "people use Windows so we develop for Windows. People develop for Windows so we use Windows" then the mainstream hardware market can start to actually invest in newer technologies (I know IBM already do) and then Windows users will finally realise the lack of support they have suffered all these years due to vendor lock-in (only Windows programs will run and only on x86). I know I will get flamed for this, but feel free to offer comments
Warbo: Here are some relevant points made in the CommunityEdgyIdeas/WindowsCompatibility page:
Better wine integration
- Add wine programs to the GNOME menu like Xfce or KDE does.
- Or make wine create shortcuts like linux programs do.
- Wine's C:/ Should be added to the nautilus Places. Since this directory is hidden in the system, it's otherwise hard to browse to.
ArtemVakhitov: speaking of fonts, one case should be specifically handled when a user installs a Windows application in Wine whose locale is different from the current one. For example, when I try to install MS Office 2000 Russian edition on C locale, I'm getting unreadable fonts. This can be worked around by prepending wine call with LC_ALL=ru_RU.utf8, but even this for some reason doesn't work reliably in all places. This may be Wine bug, but since there are ways to mitigate it, I thought I would mention this.
New Comments
Maybe you could use Wine-Doors in this spec? http://www.wine-doors.org/
- What about Windows viruses? I'm afraid that implementing this spec could make Ubuntu prone to them.
Some of Wine doors may be useful by release time, some might not be. We'll have to see where Wine is at that point. Remember that Wine doors is essentially workarounds for applications that can be made to work with Wine but don't install properly yet. As Wine fixes Wine bugs, wine-doors gets less useful (much like how WineTools is useless now). If it's still useful after a few months, at the very least, I'll make a good .deb package of wine-doors and get it into the repository.
- We're very aware of the dangers of running viruses. That's why applications don't execute on double click unless the user has either manually marked them as executable or done so through a dialog after being informed that it's a program. This way we stop all accidental viruses except for trojans that the user specifically asks to run - and those we cannot stop unless we completely take away all functionality.
- I think re-implementing winecfg using GTK would be a bit pointless. Providing there is a Ubuntu-like theme for Wine, we should be ok. Granted, it will be a bit slower to start up - but then we may want to look at optimising it's start up.
- The idea is to reduce wine configuration from the complicated mess that winecfg is to something that's only a couple of options. Upstream winecfg will always, for instance, have the sound driver selector; we can hide that relatively useless option from the user and just pick a sane Ubuntu default. Since we're redoing it anyway, it might as well be GTK.
- Providing Wine skinning support is optimised (actually, it's specifically alphablending for small tiled gradients that is slow - we should be able to write a Ubuntu-like theme that works fast enough, regardless of whether the skin slowness is fixed).
- That's a very good idea, actually. We could just edit the slow parts out of our Windows theme if we have to.
How does one help out?
Soon (possibly after a week or so) I'll be formalizing the Wine team and making it into a truly collaborative effort. There'll be a nice list of ways to help. You can always, of course, help with Wine upstream
BetterIntegratedWineSpec (last edited 2009-02-17 15:03:27 by pool-96-224-69-176)