Dash - Currently no way to find wine apps in dash other than searching them from search bar

Yup, pretty annoying.

Although narrowly speaking, adding a Wine category would make things
better, the bigger problem is that the category list seems hardcoded.
Traditional implementations of the freedesktop.org menu spec
looked at the desktop files to see what categories there were.

Correct - the current list of categories is hardcoded. That's obviously not very cool, but it needs to be that way for various technical reasons:

 - An "architectural bug" in the Unity<->Places integration makes this problematic (target for Oneiric)

 - libgnome-menu's API is too limiting to really do anything other than what it was strictly intended for. This is more problematic to tackle as libgnome-menu is in some limbo state between being deprecated and moved to some other component in the G-stack. But could also be Oneiric material to tackle in some way.

 - Unity's Dash is designed around a very flat concept (or 1 level deep if you will) for finding apps whereas the full extend of the XDG menu spec allows menus to nest arbitrarily deep. Wine utilizes deep menu hierarchies and this just doesn't map very well to the design of Unity. Do we sacrifice usability or spec compliance? I'd sac spec compliance any day, but other's may disagree. Need some discussion on this one.

 - If the Wine installer could somehow assign meaning ful XDG categories to the installed apps they would automagically show up in the existing categories. It doesn't (in all fairness because it's more or less impossible)

 - I don't see how it helps the user to put wine apps in their own dedicated category in the first place? That really seems like debugging info for us geeks spilling out into the UI to me. If I installed MS Excel I'd expect to find it in the Office category. If I installed Excel for my mother she would be very confused why she needed to look under Wine and not Office to find it.

For wine users, this is a usability problem, not a spec compliance problem.

The flat concept for finding apps breaks down when installing
Windows apps, which tend to install a handful of app menu items
in a deeply nested group. Often, these include menu items
named 'Readme' or 'Repair' whose names don't make sense without the
hierarchy. (Which of the 75 Readmes wins? Or do they all get icons? Confusing!)

This has bubbled up on the forums, e.g.
http://ubuntuforums.org/showthread.php?t=1635536

This bug means a significant step backwards from treating Wine apps as first class citizens, which is sad.

This bug is really going to frustrate new Ubuntu users who are hoping to keep a few favourite Windows apps.

Yep. Trying to find a way to place my Nook app (via wine) in the shortcut bar on the side. Don't want to use AWN or anything else. Ubuntu shouldn't require you to search through folders in order to open an application

To put it simply, installing Windows applications creates an unacceptable mess, given the current circumstances. As has been mentioned above, we don't just end up with application shortcuts, we end up with effectively orphaned readmes, help files, uninstallers, manuals, website links and all sorts of other nonsense scattered everywhere.

Please, please do something about this.

Thanks.

Totally agree with cainn24.

FL Studio creates not only the app shortcut, but links to documentation, website, specific app-settings and wrappers, etc...
Searching for "FL Studio" after installed show a lot of unintended files...

Will affect several million users, nobody seems to care, marking importance as high

For future reference; I marked bug #780576 as a dupe, but it contains relevant comments worth reading.

Here's the current status update wrt to my comment #3:

 - The "architectural bug" has been fixed in the Oneiric cycle as part of a bigger revamp of he places/lenses infrastructure. This makes it at least technically feasible to resolve this bug.

 - libgnome-menu is probably even more in limbo than I described before.

 - Afaik there has been no constructive discussion about how to resolve this issue. And as I hinted before the statement "zomg! unity is teh broken because it doesn't support nested folders!☠" is based on frustration (which I can appreciate), but also based on a wrong assumption. 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.

What I think needs to happen to move this bug forward is to have some constructive conversation around how to resolve this. Deep folder browsing is the obvious solution, but probably also the absolutely last resort as it breaks the UX horribly. So let's see if there is a more elegant way out of this.

My own best idea right now would be to not include Wine aps in the apps lens, but write a dedicated lens for Wine apps. Each app could then live in its' own cateogry, bundling all related launchers in that category. Living in a dedicated lens gives much more wiggle room for custom layout and interactions. It still doesn't entirely solve the problem in the global dash search though, where you'd end up with hits in the odd launchers...

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

I started a thread on the ayatana mailing list to gather some suggestions: https://lists.launchpad.net/ayatana/msg06684.html

Updated description with desired design solution. I understand that implementing this design may be difficult.

The "desired design solution" solves the first half of the problem described in this bug report, but not the second.

<http://blogs.msdn.com/b/b8/archive/2011/10/11/reflecting-on-your-comments-on-the-start-screen.aspx> (search for "aroush") shows how application categories may be preserved in the Windows 8 start screen.

I will note that Microsoft began tackling this problem with the "Games" list in Windows 7. The hard way -- by manually making a giant database of every application they'd ever found that was a game, and then having them shoved into a menu appropriately.

so under what app category wine apps are supposed to be shown? using 11.10 here, no existing app category seems to group wine apps, hence they are a pain to discover

Just having the option of a structured menu, and a way of adding apps to it might help. Flat is fine for people who only use a handfull of apps, but my only Ubuntu machine is a desktop, and my android device is better organised for letting me launch apps.

I do like the idea of a special Lens for WINE, seeing as it will be dedicated it would be possible to make it a Category Grouped list depending on the Folder given, eg:

----------------------
Microsoft Office
Word Excel Uninstall
----------------------
Photoshop
Photoshop ReadMe Uninstall
----------------------
Games
Serious Sam Crysis Doom 3 Far Cry Portal Half Life Uninstall ReadMe

of cause it will have the icons and the Uninstaller and ReadMe's will be unknown , perhaps the mouse Hover event can display the TRUE folder information, eg hovering Uninstall will show /Games/Doom 3/Uninstall.exe, this would enable you to know what each one is for, perhaps you could use the parent folder name in the title

----------------------
Microsoft Office
Word Excel Microsoft Office/Uninstall
----------------------
Photoshop
Photoshop Photoshop/ReadMe Photoshop/Uninstall
----------------------
Games
Serious Sam Crysis Doom 3 Far Cry Portal Half Life Doom 3/Uninstall Serious Sam/ReadMe

By using the Start menu parent it should collate them nicely even if you put them back in to the BIG Lens again actually ;)

The better idea would be to hide all items called ReadMe, Uninstall and other generic titles that are associated with WINE installs (.desktop files).

+1 to the idea for a WINE lens, but in my opinion there really should be a way of searching for stuff like the old app menu

@Scott from our very little chat at UDS you said you might be working on a scope for files lens to support WINE apps, do you still plan to do that?

Status changed to 'Confirmed' because the bug affects multiple users.

You know, you designer people annoy the hell out of me. You take a solved problem, and make it a problem all over again, and hail it as a UX breakthrough, when all you've really done is create a UX nightmare.

Nested hierarchies can handle hundreds of thousands of items without breaking a sweat, how well do you think your flat categories will scale? Not at all. Not even with search. And the fact that you *need* search is evidence that it doesn't.

Just admit it, the mobile device paradigm simply does not work on desktops. Continuing to force this nonsense is only serving to harm Ubuntu. Just as Microsoft is about to find out with Win8.

Maybe a duplicate of bug #760785?

Needs wine tab in filters

At least make a wine lens

That won't fix in unity-2d only critical issues are now considered for it.