launcher won't launch apps without desktop files

[Rachel Greenham]

Binary package hint: unity

sorry, making a concise summary defeated me on this one. :-)

If you start an application from the commandline, it runs, it puts an icon on the launcher, you can then right-click over that icon and select "Keep In Launcher". Then you quit the application. Trying to subsequently launch the application fails. The icon just pulses for a while, then gives up.

And because this is unity, I have no idea if there's a file somewhere where I can *fix* the commandline the launcher is presumably trying to use, and no idea why it's failing (though my guess is the command it stored for launching is based on something like output from ps, and doesn't actually work).

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity 3.6.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-5.32-generic 2.6.38-rc6
Uname: Linux 2.6.38-5-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,unitymtgrabhandles,scale,session,unityshell]
Date: Wed Mar 2 10:33:55 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 LANGUAGE=en_GB:en
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: Upgraded to natty on 2011-02-26 (3 days ago)

[Alex Launi (alexlauni)]

What application are you using to produce this. I just did gcalctool and it worked as one would expect.

[Rachel Greenham (rachel-strangenoises)]

On 04/03/2011 16:40, Alex Launi wrote:
> What application are you using to produce this. I just did gcalctool and
> it worked as one would expect.
>
> ** Changed in: unity
> Status: New => Incomplete
>
> ** Changed in: unity (Ubuntu)
> Status: New => Incomplete
>
Initially it was with ghb - ie Handbrake GTK as built from source and
manually installed into /usr/local/bin. I worked around that by using
checkinstall to turn it into a .deb instead and installing it as a local
package. Then I could launch it from the Apps Place and keep in launcher
and all was well.

I did check and find the same issue with some others, which I now can't
remember. Let's see if I can reproduce now...

makemkv, as built and installed from makemkv.com. Runs from commandline
(invocation: 'makemkv'; its location is /usr/bin/makemkv), appears as a
predominantly green launcher icon (bit low res but there). Keep in
Launcher, quit, try to relaunch, nothing but a pulsing launcher button.

conversely, google-chrome worked flawlessly. As of course did HandBrake
after installed as a .deb. That's the main thing I can think of;
applications installed as from a .deb work, those built and installed
according to the old-school (make && sudo make install) don't.

OK, findings from that: I checked gcalctool and that's fine. So then I
downloaded the sources to gcalctool (same version), built and installed,
with default prefix /usr/local. After hash -r the first gcalctool in
$PATH was /usr/local/bin/gcalctool. Ran that with 'gcalctool', launcher
still worked fine; ie: keep in launcher, quit, relaunch from launcher,
it worked.

Removed from launcher (unity crash, needed unity --reset), removed from
launcher again, removed OK.

Ran the built-from-source version as '/usr/local/bin/gcalctool' and it
didn't even turn up in the launcher, as if supplying a path to an
executable makes the launcher ignore it?

But remember when I was running ghb and makemkv those were invoked
without a path and the problem detailed in the bug report happened.
So... I don't know, Launcher is Weird. :-)

ghb and calctool are gtk apps, I believe makemkv is a qt app...

I just tried with xeyes (invocation: 'xeyes') and that demonstrates my
problem. That one comes with the distro, try that. :-)

--
Rachel

[Alex Launi (alexlauni)]

Ok I figured out the issue. Thanks for your help. Xeyes doesn't have an associated .desktop file. Unity uses .desktop files to launch applications, so it doesn't find the .desktop file and fails to launch.

[Chris Wilson (notgary-deactivatedaccount)]

Is this really a problem with Unity? If Unity requires a .desktop file to open the app, then isn't that an issue with the packaging?

[Rachel Greenham (rachel-strangenoises)]

ooh, this is old. My system is now on quantal alpha 1, but unfortunately I'm not with that machine at the moment, so can't test what the current behaviour is, and whether it's changed. (I'll try to remember to post an update when I get in front of it again.)

Yes you could argue it's a lack of packaging. OTOH how unity should behave when that .desktop file is absent is a valid question. What I described above was a situation where Unity was making the user promises it couldn't keep; so when it failed, it produced a bad user experience. The behaviour is particular to the unity launcher, so the fix should be too.

Specifically: When an application without a .desktop file is launched, you get a launcher icon for it, which appears to function properly. This is good.

However, when you right-click on that icon the quicklist menu offers "Keep in Launcher" (IIRC the text has changed more recently - "Lock to Launcher" now?). The existence of this menu item is the promise, inviting the user to do it, and to expect that subsequently clicking on it to launch the app will work. But it doesn't. This is the bad user experience that shouldn't happen. The promise broken.

The quick and cheap way to fix it, I'd guess, is to not have that "Keep in Launcher" / "Lock to Launcher" menu item in the quicklist menu for such apps. Presumably the launcher 'knows' that it's generated an icon without the help of a .desktop file, and could use that knowledge to simply not offer the menu item.

Then the user can't lock it to the launcher; when the app quits, it disappears from the launcher, and thus there's nothing to click and be disappointed; next time they want to launch it they have to do it the same way they did it before; from a terminal, alt-f2, whatever. No promises were made or broken. :-)

A more rolls-royce option might be for unity to instead auto-generate a basic .desktop file - enough to define the button it autogenerated when the app was run - save it in some place reserved for such auto-generated .desktop files, and then the user can still lock to launcher and when they next try to run it from the launcher, it works. I would guess that would need quite a bit more work, but it would offer a more seamless user experience for such apps. (You'd want to make sure you always prefer a packaged .desktop file if it exists, so an app that later gains one gets the benefit automatically.)

Like I said, I haven't checked what current Quantal behaviour is. I still run the same apps, but I'm used to a workflow that avoids encountering this issue. It's possible it's already been addressed since without reference to this bug and I never noticed. :-)