nautilus won't launch KDE apps

[Nicolas Riesco]

Binary package hint: nautilus

$ lsb_release -rd
Description: Ubuntu hardy (development branch)
Release: 8.04

$ apt-cache policy nautilus
nautilus:
  Installed: 1:2.22.2-0ubuntu3
  Candidate: 1:2.22.2-0ubuntu3
  Version table:
 *** 1:2.22.2-0ubuntu3 0
        500 http://gb.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

After upgrading to Hardy, I've noticed that I can't launch some KDE applications (kate, kwrite, khexedit),
either by double-clicking on a file associated to any of these apps, or by using "Open with" in the context
menu.

As a workaround to launch Kate, I have set up through the context menu > "Open with" >
 "Open with other application..." > "Use a custom command" to launch "/usr/bin/kate -u".

ProblemType: Bug
Architecture: amd64
Date: Tue Apr 15 10:39:56 2008
DistroRelease: Ubuntu 8.04
NonfreeKernelModules: nvidia
Package: nautilus 1:2.22.2-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux 2.6.24-16-generic x86_64

[Sebastien Bacher (seb128)]

the issue is due to the kde desktop files which are buggy, they use an empty path key which is not correct

[Nicolas Riesco (nicolas-riesco)]

As suggested by Sebastien Bacher, I tried in the terminal:

     cd /usr/share/applications/kde

     for x in $(grep -xl "^Path=" *.desktop) ; do sudo sed -i
's/^Path=/#Path=/' $x ; done

Then I logged out and back in, and the bug was gone.

Thanks Sebastien.

[Eric Mill (konklone)]

I can vouch for both the bug and Sebastien Bacher's solution.

I'm surprised this wasn't made a blocker, but maybe KDE app usage isn't that popular amongst most GNOME users. I use Kate for my programming, so it's been maddening for me.

[db0 (mail-dbzer0)]

I can confirm the bug on two separate workstations.

I just tried the sed fix but it will not run correctly, or so it seems.
It gives me the sed help (twice) and at the end

<code>bash: s/^Path=/#Path=/: No such file or directory</code>

[Nicolas Riesco (nicolas-riesco)]

I'm sending the workaround as an attachment.

[Jonathan Thomas (echidnaman)]

Is this a problem in Intrepid? And if so, which applications are known to be affected?

[Nicolas Riesco (nicolas-riesco)]

I don't use Intrepid (yet) but I can confirm is still present in
Hardy with the latest updates (kdebase version 4:3.5.10-0ubuntu1~hardy2)

Jonathan Thomas wrote:
> Is this a problem in Intrepid? And if so, which applications are known
> to be affected?
>
> ** Changed in: kdebase (Ubuntu)
> Status: In Progress => Incomplete
>

[Bob Philomene (bob.philomene)]

I've got the same problem in Intrepid Alpha5.
And when i tried :

cd /usr/share/applications/kde

     for x in $(grep -xl "^Path=" *.desktop) ; do sudo sed -i
's/^Path=/#Path=/' $x ; done

It's working too, like in hardy.

[Nicolas Riesco (nicolas-riesco)]

Hi again!

I haven't installed Intrepid but I've downloaded package the kate
(4:4.1.1-0ubuntu2) from:

     http://packages.ubuntu.com/intrepid/amd64/kate/download

and I can confirm that the file

     /usr/share/applications/kde4/kate.desktop

still contains an empty path key.

In hardy, these are the packages and files that need fixing:

kicker: ./usr/share/apps/kicker/menuext/find/kfind.desktop
ksnapshot: ./usr/share/applications/kde/ksnapshot.desktop
karm: ./usr/share/applications/kde/karm.desktop
korganizer: ./usr/share/applications/kde/korganizer.desktop
kfind: ./usr/share/applications/kde/Kfind.desktop
ksysguard: ./usr/share/applications/kde/ksysguard.desktop
kmix: ./usr/share/applications/kde/kmix.desktop
khexedit: ./usr/share/applications/kde/khexedit.desktop
ark: ./usr/share/applications/kde/ark.desktop
kcontrol: ./usr/share/applications/kde/kcm_kdnssd.desktop
kdvi: ./usr/share/applications/kde/kdvi.desktop
kde-guidance: ./usr/share/applications/kde/wineconfig.desktop
kpovmodeler: ./usr/share/applications/kde/kpovmodeler.desktop
kppp: ./usr/share/applications/kde/Kppp.desktop
kppp: ./usr/share/applications/kde/kppplogview.desktop
kst-bin: ./usr/share/applications/kde/kst.desktop
kate: ./usr/share/applications/kde/kate.desktop
kate: ./usr/share/applications/kde/kwrite.desktop
kooka: ./usr/share/applications/kde/kooka.desktop

Hope this helps,

Nico

[Nicolas Riesco (nicolas-riesco)]

And these are the files that I've found need fixing in Intrepid (today's live cd):

akonadi-kde: ./usr/share/kde4/apps/nepomuk/ontologies/nco.desktop
akonadi-kde: ./usr/share/kde4/apps/nepomuk/ontologies/nmo.desktop
cervisia: ./usr/share/applications/kde4/cervisia.desktop
karchiver: ./usr/share/services/karchiver_part.desktop
kate: ./usr/share/applications/kde4/kate.desktop
kfax: ./usr/share/applications/kde4/kfax.desktop
kgrab: ./usr/share/applications/kde4/kgrab.desktop
kmix: ./usr/share/applications/kde4/kmix.desktop
kompose: ./usr/share/applications/kde/kompose.desktop
kpovmodeler: ./usr/share/applications/kde4/kpovmodeler.desktop
krita-data: ./usr/share/applnk/.hidden/krita_jpeg.desktop
krita-data: ./usr/share/applnk/.hidden/krita_pdf.desktop
krita-data: ./usr/share/applnk/.hidden/krita_tiff.desktop
kst-bin: ./usr/share/applications/kde/kst.desktop
ktimetracker: ./usr/share/applications/kde4/karm.desktop

[Jonathan Thomas (echidnaman)]

Ok, the akonadi desktop files are never user visible, they are internally used.
Cervisia and kate are in kdesdk.
karchiver lives in it's own source package, it's also really old.
kfax is it's own package.
kgrab is it's own package.
kmix lives in kdemultimedia
kompose is it's own package.
kpovmodeler is it's own package
The krita ones are hidden/for internal use and shouldn't need fixing.
kst is it's own package.
ktimetracker lives in kdepim.

[Harald Sitter (apachelogger)]

As discussed with Jonathan Thomas it isn't exactly clear if empty path lines are actually considered wrong.

The Desktop Entry Specification as per http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html says the following about the value of keys which require a string:
> Values of type string may contain all ASCII characters except for control characters.
Unlike
> Values of type numeric must be a valid floating point number as recognized by the %f specifier for scanf in the C locale.
which clearly states that the key value _must_ be a valid floating point number.

String _may_ contain ASCII chars, but _may_ as well not do that. Numeric must include a valid floating point number, no content at all isn't meeting the requirements.

desktop-file-validate does also support this interpretation
> kate.desktop: warning: value "" for key "Path" in group "Desktop Entry" does not look like an absolute path
I assume if an empty value was actually breaking the standard compatibility it would use an error: instead of a warning:

Then again this might as well just be a bug in desktop-file-validate, so Jonathan is going to (or already did) get in contact with the responsible people at fd.o to get a clear definition about this.
Depending on the outcome either GNOME needs to fix it's desktop file parser, or KDE needs to get rid of all the empty keys and desktop-file-validate should be fixed to output an error for empty keys.

[Jonathan Thomas (echidnaman)]

Currently the fd.o spec regarding .desktop files is unclear about whether or not an actual path has to be specified for the Path entry. Currently .desktop files without paths (such as those from several KDE apps) explicitly passed *do* pass desktop-file-validate (with a warning, but not a failure). KDE can handle these just fine, but Nautilus has troubles.

The thing is that the spec is unclear about whether an unspecified path is valid.

The Desktop Entry Specification as per http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html says the following about the value of keys which require a string:
> Values of type string may contain all ASCII characters except for control characters.
Unlike
> Values of type numeric must be a valid floating point number as recognized by the %f specifier for scanf in the C locale.
which clearly states that the key value _must_ be a valid floating point number.

String _may_ contain ASCII chars, but _may_ as well not do that. Numeric must include a valid floating point number, no content at all isn't meeting the requirements.

That coupled with above-mentioned desktop files passing validation makes for a very confusingly-stated standard. It also makes it hard for both sides to address the problems this ambiguous statement presents.

[Jonathan Thomas (echidnaman)]

Here's the FD.o bug: https://bugs.freedesktop.org/show_bug.cgi?id=18373

[Harald Sitter (apachelogger)]

Resetting status and importance of kdesdk.
This bug is on hold until fd.o revises the spec.

[Michael Lueck (mlueck)]

subscribe

[Jonathan Thomas (echidnaman)]

Until we hear otherwise, all KDE items are spec-compliant. Invalidating until we hear otherwise from XDG (which seems not to care)

[Nicolas Riesco (nicolas-riesco)]

Since currently none of the KDE desktop files include empty Path= lines, why not finally close this bug?

[Vincent Untz (vuntz)]

Sorry for the noise, reassigning to new (since 2 years) maintainers (Ryan & David).