Comment 12 for bug 753276

"Wine assumes that it will always live in a deeply nested hierarchy that it has full control over and Unity's design policy is pretty much the converse. Flat and locked down. The Wine approach wouldn't fly on Android or iOS either."

Wine doesn't assume this, the applications do. Android and iOS have the luxury of not having tens of thousands of existing applications to worry about breaking. I tried to point it out the problem with this assumption at the very beginning of the Unity design process but it seems to have been ignored in favor of wishful thinking that either no one would want Windows applications or that somehow we'd port them all into proper Unity-compliant apps.

The latter is happening to some extent -- we'll soon have a few (hand-crafted) Wine-powered apps in Software Center with proper .desktop files. However by far the majority use case for Wine apps will be similar to Windows ones in the forseeable future - apps installed by running Windows installer files.

I agree that a Wine lens is appropriate, as we're not going to get around this issue. I might even write it myself.

To talk about something productive we can do right now, the Search interface in the application lens and Unity Dash can include the Wine subfolders as part of the name of the application when choosing whether to show it as a result. That at least makes it possible to find applications you just installed.

For instance, if you have an app that would normally be launched by something named Wine->Programs->Grand Theft Auto->Play, then searching for "Theft" should return it in the search results.