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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/727702

Title:
  launcher won't launch apps without desktop files

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/727702/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to