nepomuk:/ KIO slave does not work properly / does not exist

[Hans Bakker]

Binary package hint: kdebase

I'm running Kubuntu Lucid, all updates installed and nepomuk + strigi running.

The nepomuk KIO slave does not work properly. When clicking a nepomuk search result that points to a folder, dolphin tries to open it with an address like "nepomuk:/res/0d327547-d96a-4c1e-9727-f8ecb3cd9f7c/" and shows an error on the status bar "File or folder nepomuk:/res/0d327547-d96a-4c1e-9727-f8ecb3cd9f7c/ does not exist".

I would expect dolphin to open the found folder.

The nepomuksearch:/ and timeline:/ KIO slaves are there, the nepomuk:/ KIO slave does not seem to be available

ProblemType: Bug
Architecture: i386
Date: Sun Feb 7 19:08:55 2010
DistroRelease: Ubuntu 10.04
InstallationMedia: Kubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100207)
Package: dolphin 4:4.3.95-0ubuntu1
ProcEnviron:
 LANGUAGE=
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-12.17-generic
SourcePackage: kdebase
Uname: Linux 2.6.32-12-generic i686

[Xavier Tardivel (the-frog45)]

Same problem here under same configuration.

[Xavier Tardivel (the-frog45)]

As far as I can tell it only happens when opening a folder, for other types of resources found by krunner, it works properly.

So it might as well be a problem on Dolphin's side.

[Michael Roy (mikemlp)]

I'd just like to add that if Dolphin is set to open with the Terminal panel (F4), the terminal will navigate to the correct directory, but Dolphin will not show its contents in the center viewing pane, as others have already reported.

I'm on Karmic, using the backports PPA.

[Harald Sitter (apachelogger)]

So I did:
* tag my home folder with "foo"
* use the dolphin search bar to search for hasTag:"foo"
* my home folder is listed as result
* clicking on it works just fine and does not try to redirect to a nepomuk:/ slave

Please provide a step-by-step guide on how to reproduce this issue, but since it works on my end, I would either expect that the issue was caused by the pre-release nature of the version this was reported against, or by some nepomuk storage hickup which are not uncommon I have been told.

[Xavier Tardivel (the-frog45)]

The problem is more like :

* In my home directory I got a subdirectory named "foobar"
* Using krunner (possibly dolphin serarch bar), I search foobar
* I got a nepomuk resource being displayed in krunner results named "foobar", which is referring to my folder
* Clicking on it, Dolphin is automatically opened, (since it is a folder it makes sense) and got the error message mentioned earlier.

Your message seems to imply that I should not be able to find a "directory" if it is not tagged.

So the question remains : are folders supposed to be indexed as resources by Nepomuk ? If yes, they should be displayed correctly. If not, I should erase and reindex the content home, this time without folders.

[Hans Bakker (hansmbakker)]

Indeed, I meant what Xavier wrote. So I set it back to confirmed.

[Harald Sitter (apachelogger)]

So I search for "documents", the name of the documents folder, and I get a hit on that exact folder (which is not tagged or rated or anything) and again i can click that folder and end up in the folder via the file:// slave, still no problems.

[Harald Sitter (apachelogger)]

oh ah!

The krunner nepomuk search got a bug, that indeed makes you end up with a resource, but then again that feature got a couple more bugs.

This is however an upstream bug and should be reported on bugs.kde.org (tough I think there is already a report about this there).

For the time being you can use the search in dolphin, which works properly.

[Hans Bakker (hansmbakker)]

Sebastian Trüg confirms this bug to be solved in 4.4.1

[Xavier Tardivel (the-frog45)]

If it is fixed in the upcoming 4.4.1 released, I am not sure I can be considered to be already fixed and commited. :)

[Harald Sitter (apachelogger)]

Triage policy is to set it to fix committed, once it is committed upstream, because there is no real commit stage in Kubuntu (except for packaging-only changes).

[wofritz (wolfgang-fritz)]

Bug is still present in Beta 1 with updates up to March 20. Similar error exists with Gwenview (reported here: https://bugs.kde.org/show_bug.cgi?id=224979). For me it looks like a Kubuntu specific problem. I'll try to find another distribution with KDE 4.4.1 to cross-check.

[Jonathan Thomas (echidnaman)]

Since the actual loading of the jpg works, this seems to be a separate issue with Gwenview's nepomuk implementation. (I can for example open things via nepomuk in ark just fine)