Wine applications not listed in Unity Applications Place

[Adam Guthrie]

Binary package hint: unity-place-applications

Wine applications have .desktop and .menu files and show in Gnome application menu but cannot be found using Unity. e.g. I have

~/.local/share/applications/wine-Programs-Spotify.desktop
~/.config/menus/applications-merged/wine-Programs-Spotify.menu

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: unity-place-applications 0.2.18-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic i686
Architecture: i386
Date: Fri Sep 10 19:46:53 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu-Netbook 10.10 "Maverick Meerkat" - Alpha i386 (20100803.1)
ProcEnviron:
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: unity-place-applications

[Sense Egbert Hofstede (sense)]

I'm marking this bug as Triaged since I can confirm the issue myself as well and since an upstream task has been opened. I'm leaving the status to Undecided for the Unity Team to decide themselves.
This is something that I would be glad to see fixed before the release of Maverick, though, because it could confuse users and hide applications installed in Wine.

[Mark Shuttleworth (sabdfl)]

A patch would be welcome, but this isn't something we're likely to be
able to fix ourselves pre-Maverick.

[Adam Guthrie (therigu)]

The problem seems to be that my wine .desktop files have no Category value, and hence unity-applications-daemon is skipping them whilst indexing the gmenu.

Sense, is this the same for you?

Attached is a patch to unity-application-daemon to allow category-less menu entries, whilst still trying to guard against the case where unity cannot find a .desktop file.

[Mark Shuttleworth (sabdfl)]

Adam, Sense, thanks for the patch I'll ask Mikkel to take a look.

[Sense Egbert Hofstede (sense)]

I can confirm that *.desktop files generated by Wine indeed don't contain a category.
It is tricky to make sure the categories do end up correctly in these files since Wine has no source to draw the information from. On top of that, you could ask yourself whether it would be desired behaviour to have Windows applications run via Wine show up in the regular categories.

Adam, if I read your patch correctly, you don't create a separate category for Wine applications, or any category-less applications, but only make sure the Wine applications are part of Unity's 'All Applications' search domain, right?
This seems like a good solution to me.

Would adding a separate category for Wine applications be an option as well? We could make Wine add a category 'Wine' to all *.desktop files it generates, and make those show up under a heading like 'Windows applications' or 'Wine'. Problem: how do we convey to a user the meaning of this separate category when a lot of people already seem to have troubles understanding that applications for Windows cannot run (natively) on Linux distributions or Mac OS?

[Mark Shuttleworth (sabdfl)]

 On 18/09/10 19:22, Sense Hofstede wrote:
> Would adding a separate category for Wine applications be an option as
> well?

I'd suggest we start with integrating those apps into the existing
categories. If it later becomes evident that a separate category would
be better, we can do the work then.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Thanks for you work on this Adam! I have not reviewed the patch yet, but I need to know if you have signed the contributor agreement?

I am a bit cautious of indexing stuff that doesn't have an XDG category, since all sorts of .desktop files we don't want to show also does not have categories and I am not confident that we can trust them to always set the NoDisplay=True field. OTOH - maybe we can. Will investigate thoroughly.

[Mark Shuttleworth (sabdfl)]

Ah, I didn't realise that Wine apps don't have categories provided -
makes sense though if you think that they are just Windows apps, there's
no packaging. OK, perhaps a Wine category is needed then, to do this
properly. It should of course only show up if there are Wine apps installed.

[Adam Guthrie (therigu)]

Are wine apps going to be the only ones missing categories?

As far as I can see the specs say that specifying categories is optional in .desktop files.

Shouldn't we be fixing .desktop files that are missing nodisplay or excluding them explicitly in the unity-place-applications.menu?

I don't like the idea of hiding apps that are implementing the spec correctly, especially as this seems to be the only user friendly way of launching apps in unity. This is especially pressing for wine where the .desktop files are in hidden directories.

I'm unaware of a contributors agreement - can you enlighten me?!

----- Reply message -----
From: "Mark Shuttleworth" <email address hidden>
Date: Sun, Sep 19, 2010 21:47
Subject: [Bug 635223] Re: Wine applications not listed in Unity Applications Place
To: <email address hidden>

Ah, I didn't realise that Wine apps don't have categories provided -
makes sense though if you think that they are just Windows apps, there's
no packaging. OK, perhaps a Wine category is needed then, to do this
properly. It should of course only show up if there are Wine apps installed.

--
Wine applications not listed in Unity Applications Place
https://bugs.launchpad.net/bugs/635223
You received this bug notification because you are a direct subscriber
of the bug.

Status in Unity: Triaged
Status in Unity Applications Place: New
Status in “unity-place-applications” package in Ubuntu: Triaged

Bug description:
Binary package hint: unity-place-applications

Wine applications have .desktop and .menu files and show in Gnome application menu but cannot be found using Unity. e.g. I have

~/.local/share/applications/wine-Programs-Spotify.desktop
~/.config/menus/applications-merged/wine-Programs-Spotify.menu

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: unity-place-applications 0.2.18-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-20.29-generic 2.6.35.4
Uname: Linux 2.6.35-20-generic i686
Architecture: i386
Date: Fri Sep 10 19:46:53 2010
EcryptfsInUse: Yes
InstallationMedia: Ubuntu-Netbook 10.10 "Maverick Meerkat" - Alpha i386 (20100803.1)
ProcEnviron:
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: unity-place-applications

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/unity/+bug/635223/+subscribe

[Scott Ritchie (scottritchie)]

Why isn't Unity doing the exact thing Gnome is here?

[Mark Shuttleworth (sabdfl)]

 On 19/09/10 22:12, Adam Guthrie wrote:
> Are wine apps going to be the only ones missing categories?
>
> As far as I can see the specs say that specifying categories is optional
> in .desktop files.
>
> Shouldn't we be fixing .desktop files that are missing nodisplay or
> excluding them explicitly in the unity-place-applications.menu?
>
> I don't like the idea of hiding apps that are implementing the spec
> correctly, especially as this seems to be the only user friendly way of
> launching apps in unity. This is especially pressing for wine where the
> .desktop files are in hidden directories.

Agreed

> I'm unaware of a contributors agreement - can you enlighten me?!

http://www.canonical.com/contributors

Mark

[Mark Shuttleworth (sabdfl)]

 On 19/09/10 23:24, Scott Ritchie wrote:
> Why isn't Unity doing the exact thing Gnome is here?

What's the pattern there?

[Scott Ritchie (scottritchie)]

Installation of Wine package provides some .directory files in ~/.local/share/desktop-directories - these provide folders for the "wine" and "Programs" namespace. However, these are duplicated by the .directory files the package itself provides so they should get ignored (the package provides them so the Wine folder appears after installing the package but before running Wine, as well as to populate the initial links such as Browse C: Drive)

After installing programs, Wine then adds .desktop files in subfolders within ~/.local/share/applications/wine/Programs. These don't contain a category, however Gnome is smart enough to put them in the appropriate folder, because it learns this via their path.

In the past I seem to remember a bug or two about Wine links just appearing entirely within Applications->Other (rather than their proper subfolders, eg Wine->Programs->World of Warcraft), presumably because the directories stopped being read.

[Mark Shuttleworth (sabdfl)]

OK, Let's take Scott Ritchie's guidance as canonical on this, it may not
get done for Maverick but a patch implementing this properly with tests
would be accepted as a contribution.

Mark

[Mikkel Kamstrup Erlandsen (kamstrup)]

> Why isn't Unity doing the exact thing Gnome is here?

Because Unity is not centered around a hierarchical menu like Gnome is. We only support one level of categories (ie no submenus) and the categories are lined up horizontally, not vertically, which makes them fill up the available space quickly - ie. we can not just start arbitrarily adding elements to the end of the category list - it would overflow the screen.

Also the browsing and searching is integrated with the software center with all available apps. Which means that a category can easily contain hundreds of items (even thousands), not just the few handfuls you see on a desktop installation.

These features gives Unity some requirements that does not integrate particularly well with the whole XDG menu spec or how Gnome does things. Not saying it's impossible, but just that we can't simply take libgnome-menu off the shelf and be happy.

[Scott Ritchie (scottritchie)]

The best you can do then is dump them all into a Wine category, which would be assumed from the path in the same way that the Gnome menu assumes Wine apps go into the Wine subfolders. The user can then prune the cruft.

That still leaves a lot of problems of course - Windows apps like to put a lot more than a single link to themselves since they expect to be in subfolders, and there's no way to programatically determine which is the "right" one the user wants. Making a massive database of categories for Wine apps like Mark alluded to earlier has been suggested before, but it's also fairly unworkable: we still have the problem of what to do with the other links a program might make, and as long as some apps aren't covered the user will reasonably expect ALL their apps to appear in the Wine category.

Relatedly, I had plans (and an initial, now non-applying implementation) of a way for Wine apps to appear in Software Center, however in that case it was only the uninstallers. I would still like for this to happen "eventually", as a unified way of removing software and being able to get rid of the Wine uninstaller link.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I pushed up a branch much similar to Adam's idea (thanks taking a shot at this Adam!). It will result in Wine apps showing up (and being searchable) under All Applications, but they can not be launched - and that seems to be a way trickier issue to resolve...

I installed Songbird's Windows version with Wine. This gives me 4 .desktop files in /home/kamstrup/.local/share/applications/wine/Programs/Songbird/Songbird*.desktop. When I ask libgnome-menu for the desktop id for any of these apps I get a string like: wine-Programs-Songbird-Songbird (Profile Manager).desktop

The problem is that Unity relies heavily on "desktop ids" everywhere, which is defined to be the basename of the .desktop file including the extension. Ie. Firefox has firefox.desktop as desktop id. By virtue of the XDG Menu Spec we search for applications/$desktop_id in $XDG_DATA_DIRS and ~/.local/share in order to find the right .desktop file to launch.

Thus we expect the Songbird desktop files as: /home/kamstrup/.local/share/applications/wine-Programs-Songbird-Songbird (Profile Manager).desktop, but this is not where we can find them. I am not sure exactly how to resolve this - since breaking the invariant that we use desktop ids to identify applications will bring in a bucket load of collateral problems...

[David Barth (dbarth)]

The change is not trivial, and I'm concerned that it can have impacts that we can't totally manage at this late stage of the development cycle.

I propose to document a workaround in the release notes, consisting in moving the wine .desktop files to one of the XDG directories we monitor.

In parallel, we can try and test the different solutions that are proposed, provide that in a PPA to be later propoesd as a SRU.

[David Barth (dbarth)]

Moving the bug to the backlog to be considered for an SRU

[Mikkel Kamstrup Erlandsen (kamstrup)]

I tried to figure out the ramifications of this and it seems to be pretty tangled up. Giving a high risk of breakage if we rush it at this late point in the cycle.

Here's what I know:

 * The following modules are based on the assumption that they deal with desktop ids: zeitgeist, zeitgeist-fts-extension, zeitgeist-gio, unity, libunity, unity-place-applications (perhaps also unity-place-files)

 * bamf and the launcher also breaks on Wine apps: When running a Wine app I get a generic Wine icon (the wineglass one) in the launcher with title "Wine Windows Program Loader". Clicking on focuses the app all right. If I persist the Wine icon in the launcher (wing off "Keep in launcher") and close the app, I can not launch the app again, but get the error dialog: "The file 'wine' is not marked as executable. If this was downloaded or copied from an untrusted source, it may be dangerous to run. For more details, read about the executable bit."

So pretty much everything in Unity except the panel has to be audited in order to provide a smooth experience here.

Solution:
 * If my analysis above turns out to be over dramatic we can maybe land it as an SRU if the desktop team agrees

 * If my analysis turns out to contain about the right amount of drama we can land the required workarounds in Natty

 * Personally I'd prefer that Wine apps start following the xdg menu spec to the letter, in which case it ought to "just work". This is definitely out of scope for maverick, but could be a target for Natty, but afaik, this is really out of our hands. We could engage upstream here.

[Mark Shuttleworth (sabdfl)]

Agreed that we drop this for Maverick and focus on it for Natty. We
should document a manual workaround for folks to provide the needed
category for Wine apps manually, if they really need it.

Ask a question to Scott Richie - could we make this part of the Wine app
installation process, that people specify a category for the app, if we
don't have one in a database?

Mark

[Adam Guthrie (therigu)]

@all, thanks for looking into this.

@Mikkel, I've looked at your analysis and tried a test case and agree. However, I believe unity isn't implementing the XDG spec fully. The spec [1], says this about <AppDir>s:

If the directory contains sub-directories then these sub-directories should be (recursively) scanned as well. The name of the subdirectory should be added as prefix to the desktop-file id together with a dash character ("-") So given a <AppDir> /foo/bar and desktop entry /foo/bar/booz/Hello.desktop the desktop entry would get a desktop-file id of booz-Hello.desktop A desktop entry /foo/bar/bo/oz/Hello.desktop would result in a desktop-file id of bo-oz-Hello.desktop

Therefore I believe unity should be searching for the desktop file for id bo-oz-Hello in applications/bo-oz-Hello.desktop and applications/bo/oz/Hello.desktop with the former taking precedence it it exists.

Do you agree?

Also, I'm sure I had a ~/.local/share/applications/wine-Programs-Spotify.desktop at one point, which is why my fix worked for me. However, cleaning out wine completely and re-installing, I don't any longer.

@Scott, any idea why this is?

A work around for all this seems to be:

Add "Categories=wine" into ~/.local/share/applications/wine/Programs/Spotify.desktop
ln -s ~/.local/share/applications/wine/Programs/Spotify.deskop ~/.local/share/applications/wine-Programs-Spotify.desktop

This allows wine apps to be searched for and launched via unity. although the icon is still wrong (it's the wine icon - this is the problem with bamf AFAIK).

[1] http://standards.freedesktop.org/menu-spec/menu-spec-latest.html

[Mikkel Kamstrup Erlandsen (kamstrup)]

You're right Adam. You got me there. I have actually never noticed that particular paragraph in the spec before :-) Thanks for digging into this!

It is, however, a pretty nasty part of the spec since it requires excessive stat()ing of files. Consider:

  /home/kamstrup/.local/share/applications/wine-Programs-Songbird-Songbird (Profile Manager).desktop

This maps down to 2^3=8 possible paths the .desktop file could live under (all permutations of - and /) since '-' is also a legal character in a desktop file id (consider gnome-power-preferences.desktop).

To make matters slightly ridiculous: If I had a file /usr/share/applications/gnome/power/preferences.desktop, and that file was included from an <AppDir> element at any later point in the .menu file than gnome-power-preferences.desktop; then the spec tells us that this file (preferences.desktop) takes precedence over gnome-power-preferences.desktop. Go figure :-)

Nonetheless we need to look into this for Natty. If we can make it work with Wine programs across the stack we could consider an SRU for Maverick, but to be honest I fear that these changes have non-trivial ramifications.

[Mark Shuttleworth (sabdfl)]

We don't need to comply with the spec if it's badly considered; we could
propose an update to the spec that lends itself to non-pathological
implementations :-)

[Damjan Jovanovic (damjan-jov)]

As the writer of winemenubuilder, the part of Wine that builds freedesktop menus, I have this to add.

The menu structure is driven by the per-shortcut .menu files under ~/.config/menus/applications-merged. The .directory files in ~/.local/share/desktop-directories and the .desktop files in ~/.local/share/applications/wine/... are referenced from the .menu file to describe and thumbnail the subdirectories and shortcut. Thus the .menu file is crucial, it is what places the icon in the right place, and it is the absence of the .menu file that causes the .desktop entry to appears under "Other" in Gnome. If you want to build a single flat menu structure without subdirectories, good luck: most uninstallers for Windows applications are all named "Uninstall". Mint 8 tried the single flat menu idea and it didn't work that well for Wine.

The poorly researched "desktop-id" idea is, in my understanding, fundamentally broken and will regress not only Wine but Java and any other framework that launches through a layer of indirection (eg. .desktop file launched "java -jar ..." or "/bin/sh ...", which then starts the real application).

[Mikkel Kamstrup Erlandsen (kamstrup)]

On 28 September 2010 11:40, Damjan Jovanovic <email address hidden> wrote:
> As the writer of winemenubuilder, the part of Wine that builds
> freedesktop menus, I have this to add.

Cool. Nice to have you in the discussion! :-)

> The menu structure is driven by the per-shortcut .menu files under
> ~/.config/menus/applications-merged. The .directory files in
> ~/.local/share/desktop-directories and the .desktop files in
> ~/.local/share/applications/wine/... are referenced from the .menu file
> to describe and thumbnail the subdirectories and shortcut. Thus the
> .menu file is crucial, it is what places the icon in the right place,
> and it is the absence of the .menu file that causes the .desktop entry
> to appears under "Other" in Gnome. If you want to build a single flat
> menu structure without subdirectories, good luck: most uninstallers for
> Windows applications are all named "Uninstall". Mint 8 tried the single
> flat menu idea and it didn't work that well for Wine.

Ok - this is nice to know. I actually have the icons working out ok,
in my testing branch for the places. It's just the launcher tiles
which are wrong, i haven't even tried fixing that yet. So I'm
confident that we can get this to work throughout.

The tricky part is figuring out what to do with overly generic
application names like "Uninstall". Atleast Songbird has
Name=Uninstall Songbird and a custom unistaller icon - so that should
be easy for users to distinguis in the UI. Just goes to show that not
all apps are problematic in this regard at least :-)

> The poorly researched "desktop-id" idea is, in my understanding,
> fundamentally broken and will regress not only Wine but Java and any
> other framework that launches through a layer of indirection (eg.
> .desktop file launched "java -jar ..." or "/bin/sh ...", which then
> starts the real application).

I am not sure I totally understand what you're getting at here? Is it
that you simply don't believe that you can assign unique identifiers
to applications, or is it that the matching of window -> .desktop file
is not ever gonna work?

Window matching is definitely a tricky business - but ditching the
entire idea because it's hard to get all the details right seems a bit
radical to me. Even though it might not be perfect in the first go, I
believe we can get there with some work.

[Damjan Jovanovic (damjan-jov)]

In Wine the general policy is only freedesktop specifications are supported, no desktop-specific hacks.

There isn't any cross-desktop spec for matching windows -> .desktop files, but http://live.gnome.org/GnomeShell/ApplicationBased seems like a good place to start:

"To ensure the GNOME 3 Shell will track your application, you can also set the WM_CLASS X window property to be the same as your application's .desktop file name, without the .desktop extension. The easiest way to achieve this is to have your application's process name match the .desktop file name, and ensure you use g_option_context_parse."

But:
1. The executable name trick is unusable by Wine, Java, Mono, Python and other frameworks. In a later section, "Binding interpreters", the document explains those applications should manually set the WM_CLASS from a-priori knowledge of the .desktop file name, which is still just as unobtainable.
2. *nix vendors have used WM_CLASS for custom purposes for years, it will be difficult to get them all to change now:
eg. $ xprop | grep WM_CLASS (on a Java application)
WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "java-lang-Thread"

Is Unity using the Gnome 3 spec or doing something else?

[Mikkel Kamstrup Erlandsen (kamstrup)]

On 28 September 2010 13:22, Damjan Jovanovic <email address hidden> wrote:
> In Wine the general policy is only freedesktop specifications are
> supported, no desktop-specific hacks.
>
> There isn't any cross-desktop spec for matching windows -> .desktop
> files, but http://live.gnome.org/GnomeShell/ApplicationBased seems like
> a good place to start:
>
> "To ensure the GNOME 3 Shell will track your application, you can also
> set the WM_CLASS X window property to be the same as your application's
> .desktop file name, without the .desktop extension. The easiest way to
> achieve this is to have your application's process name match the
> .desktop file name, and ensure you use g_option_context_parse."

It also says:

"There are a variety of heuristics used to make the association
between X windows and .desktop files for backwards compatibility.
These heuristics are complex and still evolving, and will not be
detailed here. "

So basing anything off that seems risky business.

Unity is using BAMF (hosted on lp:bamf) to do window matching. To know
the details of how it works you'd have to consult with Jason Smith,
but to my knowledge it tries to do exact matching by using an index of
the .desktop files and if unsuccessful it falls back to a net of
heuristics.

I can appreciate that all apps needing a "dispatcher" are in trouble
here. For setting the program name one could use prctl(), but that
would not work in general. We're probably never gonna go completely
without a set of heuristics, and I don't think anyone expects
otherwise.

I'll try to get Jason's input on this.

--
Cheers,
Mikkel

[Jason Smith (jassmith)]

BAMF goes through 3 layers of matching before falling back to a "failure" state where no .desktop file is associated. The layers in short are:

1) A gio module which directly informs bamf which PID is launched with which .desktop file
2) wm-class <-> desktop_id association
3) heuristics (sloppy)

In the case of wine it uses 3 or 4 layers of indirection on launch, so the gio module rarely works because the final running pid does not match the pid the .desktop file launchers. The wm_class of all wine applications is handidly "Wine" making them difficult to distinguish from one another and their running executable strings are usually less than helpful.

There is however a way forward.

Wine seems to set the name of the exe in an xproperty on the window. Using a search of known .desktop files exec lines, the correct (or at least the usually correct assuming not too many programs are installed) .desktop file could be picked out. This would give a better image, savability on the launcher, and generally proper behavior in Unity.

Workload wise this is more of a testing issue than a coding issue. I can ensure songbird works today, but a small list of 10 or so wine apps (and maybe a dude to help test) that are considered "common" would be awesome.

Summary:
Coding is not a problem. Special casing will ensure this does not effect existing applications. Workload is primarily in the testing phase.

[Jason Smith (jassmith)]

I forgot to mention that we consider the GNOME Shell method of doing matching to be "fallback" matching as the gio module is considerably more accurate when it works (no indirection).

[Ferry Toth (ftoth)]

I may be missing the point here but...

1) the netbook-launcher in Lucid did pretty much the same job: transform the free-desktop structures into a flat structure. Why not do the same here?
2) Using the menu editor you could (Lucid UNE) hide unnecessary cruft from appearing under the wine folder in netbook-launcher (like the uninstall programs)
3) Unity normally runs on netbooks. How many wine items would a user install? If they are like me they would attempt M$ Office, as OO does not handle all Word and Powerpoint files well. They might even install some(few) other windows programs for which they have no linux equivalent. But thousands? Come on, wine does not work that well yet.
4) A lot of installed programs don't show up now. In my case for example nautilus. Don't know why.
5) A lot of unnecessary junk does appear. I have configuration editor 3x. In the past I would just hide 2 of them using the menu editor.

As it stands now, netbook-launcher did much the same as Unity, but without the limitations. But I already start to like Unity and would not want to replace it permanently. But I think half a year is a long wait, to long.

For the most visible app in Ubuntu netbook, I think it deserves a high priority to get fixed.

Ferry

[Oleksij Rempel (olerem)]

Currently Bug #667690 market us duplicate of this bug, unfortunately it is not. Please can any one confirm it?
here is screen shout what shows double menu entry after app started:
http://launchpadlibrarian.net/58392587/Bildschirmfoto-gnome-sound-record-1.ogv-2.png

and this can be "fixed", after switch the app off and on fullscreen again.
http://launchpadlibrarian.net/58392223/gnome-sound-record-1.ogv

The second issue is, no visual feedback after icon was clicked. Wine apps start usually slow, even i not always sure did i pressed the button or not.

[Romano Giannetti (romano-giannetti)]

Just to add my two (euro)cents here, notice that the same happens to CrossOver applications. They works well launched by command-line or via nautilus application etc, but they do not appear anywhere in Unity. Nor the CrossOver setup etc. It seems that all applications that create a new top-level entry in normal gnome -> application menu are not available in Unity application menu.

[David Barth (dbarth)]

We need some design guidance on how best to organize things for Wine applications.

[Libertas (libertas-mania)]

Seeing as more than just Wine apps can not include the category line I feel it best that Unity should place all these items into the Other Section, at least they are then accessible to the user to run from Unity.

As for Uninstall and other duplicate names, these should ALL get hidden from the menu system, they are usually junk. To remove your programs you simply run an uninstall tool to do so, or browse to the install location and run Uninstall.exe manually from there.

By complicating the method that the links are available/search-able to Unity will not only slow down the desktop, but will also be more prone to errors. I hope that in Future Unity will provide a way to build up your own Menu categories and apply items to them, AND make it transferable to other PC's easily, this will enable the end user to customize the menu structure for their network/friends/respins.

The other method we could use is a post install linux app that you can run that will recreate the .desktop and .menu files to be identifiable from unity, by offering a update-able database of common Windows applications this will allow for category sorting to also take effect.

The simplest solution is the best one, in these cases - and all that requires is that apps without a category go to the Other menu category to allow Unity search to find them (or add them to the Applications drop down list). As for the icons, the .desktop file is already linked to the .menu file, we could easily set the icon file in the .desktop to point to the same file (so long as the exe icon extraction is still functioning).

The last solution I can think of is a method to call a custom Menu system to the panel list, one that uses the gnome methods to list any and all items it finds, instead of the bias way unity does it :D

Just some ideas, hope to see this problem resolved soon.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I want to clear up the reason why I am hesitating a bit to jump right into this. Not saying we shouldn't fix it, definitely we should! Just that I am hesitating, to contemplate it a bit.

The XDG desktop file spec (or is it the menu spec?) dictates that to compute the desktop file id of something nested in the applications dir you substitute all slashes "/" for dashes "-". So fx. ~/.local/share/applications/wine/Programs/Songbird/Songbird.desktop has desktop file id wine-Programs-Songbird-Songbird.desktop. So when we look it up by id we need to check 8 permutations of / and - (in the worst case). That is 8 stat()s instead of 1.

The big problem is that in order to be 100% consistent we must support this on *all* .desktop files with - in the basename, not just wine files. I quick series of shell commands show that I have 727 -s in desktop file names in /usr/share/applications and /usr/share/app-install/desktop in total. The number of needed (worst case) permutations is prolly a bit bigger becomes some files have more than one - in the name; so roughly maybe around 1000k extra stat() calls.

Needless to say; we can apply a lot of tricks to get *well* below the worst case number of 1k extra stat()s; but it goes to show that the XDG spec is particularly bad at this point, and it's not something we should just dive into head first. It may give a non-trivial impact on startup performance.

[Damjan Jovanovic (damjan-jov)]

You could of course cache all .desktop files, build a suffix tree or suffix array data structure, and then use longest-prefix matching instead of stat()ing every possibility.

[Mikkel Kamstrup Erlandsen (kamstrup)]

@Damjan: Sure, but that would otoh mean I'd have to scan all application dirs recursively. In order to get the smallest hit on startup I fetch everything lazily. But as said; it's not that it's super tricky to optimize or anything, it just requires a little more than 3 lines of code to do properly.

[Tyler Mendenhall (tcm618)]

For anybody who is interested in a temporary work-around for Maverick Meerkat 10.10:

If you log into your account via a regular Ubuntu Desktop Edition or other session that you can access the wine *.desktop programs, install an application called Docky from the Software Center. Drop the Wine app's that you want into Docky and they will then show up and be accessible.

I would rather have the app's in the Unity launcher but at the moment that doesn't seem to be an option, so Docky get's the job done for me by (I'm guessing) pre-cataloging the location of the programs.

[Alessandro Pedarra (alessandro-pedarra)]

Please fix it at the earliest, it's a show stopper for a lot of people. Can't you just copy Gnome 3 on that?

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-place-applications - 0.2.40-0ubuntu1

---------------
unity-place-applications (0.2.40-0ubuntu1) natty; urgency=low

  * New upstream release.
    - unity-applications-daemon crashed with SIGSEGV in
      Xapian::MSetIterator::operator*() (LP: #732945)
    - Dash: Alt-F2 box hint says "Search commands" not "Run a
      command"/"Execute command" (LP: #733897)
    - Wine applications not listed in Unity Applications Place (LP: #635223)
    - Add application through "main menu" won't work (LP: #734042)
    - Unable to scroll with wheel in unity places (LP: #732012)
    - unity about:config should launch ccsm on the unityshell plugin page
      (LP: #736765)
  * debian/control:
    - build-dep on latest dee
 -- Didier Roche <email address hidden> Thu, 17 Mar 2011 16:20:28 +0100

[Sven Rieke (sven-rieke)]

In my case, this issue isn't fixed yet.
I'm using Natty and have unity-place-applications-0.2.46-0ubuntu3 installed right now.

I'm still missing several applications that I had in my Gnome 10.10, especially all menu entries from Crossover.
Some (not all) of my manual entries are accessible, but it seems that the ones which had several nesting levels in the menu aren't shown by Unity.