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

Bug #753276 reported by dart
302
This bug affects 66 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Fix Committed
Low
John Lea
Unity
Triaged
Low
Unassigned
unity-2d
Invalid
High
Unassigned
unity (Ubuntu)
Triaged
Low
Unassigned
unity-lens-applications (Ubuntu)
Triaged
Low
Unassigned

Bug Description

There is no dedicated wine category/folder in dash where we can find wine apps at one place. Wine apps show in search results and under all applications category but user must be aware all the time about what apps he has installed. This seems a bit awkward and there should be a dedicated 'wine apps' category.

Also, in classic gnome, wine menus are nested and properly categorized so that we can easily know which is parent menu and what apps fall under it. This seems not to be the case with unity.

--------------------------

Desired design solution:

- wine apps that are currently installed should be displayed underneath the "Installed" Dash App Lens category header. They should also be searchable through both the Dash Home and the App Lens.
- wine apps that are present in the Software Centre should be displayed underneath the "Apps Available for Download" Dash App Lens category header

dart (dart-v85)
description: updated
Revision history for this message
Dan Kegel (dank) wrote :

Yup, pretty annoying.

Doug McMahon (mc3man)
Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity:
status: New → Confirmed
Revision history for this message
Dan Kegel (dank) wrote :

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.

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

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.

Changed in unity-2d:
status: New → Confirmed
Changed in unity-2d:
importance: Undecided → High
importance: High → Wishlist
Revision history for this message
Dan Kegel (dank) wrote :

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.

Revision history for this message
Roger Leyland (rogerandliz) wrote :

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

Changed in unity-2d (Ubuntu):
status: New → Confirmed
Revision history for this message
JHansonJr (james-l-hanson) wrote :

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

Revision history for this message
cainn24 (cainn) wrote :

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.

Revision history for this message
falkTX (Old) (falk-t-j) wrote :

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

Revision history for this message
Scott Ritchie (scottritchie) wrote :

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

Changed in unity (Ubuntu):
importance: Undecided → High
Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

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

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

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

Changed in unity-lens-applications:
status: New → Confirmed
Changed in unity:
importance: Undecided → High
Changed in unity-lens-applications:
importance: Undecided → High
Changed in unity-2d (Ubuntu):
importance: Undecided → High
Changed in unity-lens-applications (Ubuntu):
status: New → Confirmed
Revision history for this message
Scott Ritchie (scottritchie) wrote :

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

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

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

Revision history for this message
John Lea (johnlea) wrote :

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

description: updated
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → High
status: New → Fix Committed
tags: added: onew udo
Changed in unity-2d:
importance: Wishlist → High
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

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.

Revision history for this message
Scott Ritchie (scottritchie) wrote :

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.

Revision history for this message
Ari (ari-reads) wrote :

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

Revision history for this message
tsh (tsh) wrote :

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.

John Lea (johnlea)
Changed in ayatana-design:
status: Fix Committed → Triaged
Changed in unity:
milestone: none → backlog
tags: added: udp
Mirco Müller (macslow)
Changed in unity-lens-applications:
assignee: nobody → Mikkel Kamstrup Erlandsen (kamstrup)
John Lea (johnlea)
Changed in ayatana-design:
status: Triaged → Fix Committed
Revision history for this message
Glenn Chugg (glennlchugg) wrote :

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

Revision history for this message
Aditya V (kroq-gar78) wrote :

+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

Revision history for this message
Omer Akram (om26er) wrote :

@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?

Vishal Tailor (vdtailor)
Changed in unity-lens-applications:
assignee: Mikkel Kamstrup Erlandsen (kamstrup) → Vishal Tailor (vdtailor)
affects: unity-lens-applications → ubuntu
Changed in ubuntu:
status: Confirmed → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu:
status: New → Confirmed
Revision history for this message
aidanjt (aidanjt) wrote :

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.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Maybe a duplicate of bug #760785?

Revision history for this message
Zies McDoom (jasonflindt) wrote :

Needs wine tab in filters

Revision history for this message
Zies McDoom (jasonflindt) wrote :

At least make a wine lens

Omer Akram (om26er)
tags: added: wine
Revision history for this message
Omer Akram (om26er) wrote :

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

no longer affects: ubuntu
Changed in unity-2d (Ubuntu):
status: Confirmed → Won't Fix
Changed in unity-2d:
status: Confirmed → Invalid
John Lea (johnlea)
no longer affects: unity-2d (Ubuntu)
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Changed in unity-lens-applications (Ubuntu):
status: Confirmed → Triaged
Changed in unity:
status: Confirmed → Triaged
Tim Penhey (thumper)
Changed in unity:
milestone: backlog → none
Tim Penhey (thumper)
tags: added: exbacklog
John Lea (johnlea)
Changed in ayatana-design:
importance: High → Medium
Changed in unity (Ubuntu):
importance: High → Medium
Changed in unity:
importance: High → Medium
John Lea (johnlea)
Changed in ayatana-design:
importance: Medium → Low
Changed in unity:
importance: Medium → Low
Changed in unity-lens-applications (Ubuntu):
importance: Undecided → Low
Changed in unity (Ubuntu):
importance: Medium → Low
summary: - Currently no way to find wine apps in dash other than searching them
- from search bar
+ Dash - Currently no way to find wine apps in dash other than searching
+ them from search bar
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.