Bug 311468

Created attachment 75768 [details]
Example in dolphin and kdialog

Example of the bug in dolphin (showing encoded umlauts) and kdialog (in the background, showing an encoded space)

Seems to be related on how they are created in 

KIO::UDSEntry createUDSEntryForTag(const QUrl& tagUri, const QString& label) 
in kio_tags.cpp, and quite probably related to http://lists.kde.org/?l=kde-core-devel&m=134505764027817

it would be nice if this could be fixed for 4.10, either decoding the URL encoding for the display name, or by alter how dolphin / konqueror and the like display them. 

Not being a dev, but if there already is a separate field for the display name, maybe this should be used for a human readable form. Then all the places where they are used, including kdialog, would not have to be adapted. 

Thanks in advance, kind regards

Workaround: 

--- kio_tags.cpp        2013-01-19 23:09:06.946564839 +0100
+++ kio_tags.cpp.new    2013-01-19 23:09:51.169897908 +0100
@@ -123,8 +123,9 @@
 
         KIO::UDSEntry uds;
         uds.insert( KIO::UDSEntry::UDS_NAME, label );
-        uds.insert( KIO::UDSEntry::UDS_DISPLAY_NAME, label );
-        uds.insert( KIO::UDSEntry::UDS_FILE_TYPE, S_IFDIR );
+       QString displayLabel = QUrl::fromPercentEncoding(label.toUtf8());
+       uds.insert( KIO::UDSEntry::UDS_DISPLAY_NAME, displayLabel );
+       uds.insert( KIO::UDSEntry::UDS_FILE_TYPE, S_IFDIR );
         uds.insert( KIO::UDSEntry::UDS_MIME_TYPE, QString::fromLatin1( "inode/directory" ) );
         uds.insert( KIO::UDSEntry::UDS_DISPLAY_TYPE, i18n( "Tag" ) );
         uds.insert( KIO::UDSEntry::UDS_MODIFICATION_TIME, dt.toTime_t() );

Works here in both dolphin and kdialog. 
Not knowing the internals of UDSEntry and nepomuk: if DISPLAY_NAME is what the name suggests, then maybe the decoded version should be used there indeed. 

Doing a bit of searching around, it seems that this is a known problem in QUrl and might be fixed in KUrl, but it seems that QUrl is used all over the place. So if this workaround has no downsides, maybe including it for 4.10  would be nice, so users with tags containing accents, umlauts or whitespaces can enjoy this new kioslave.

I cannot seem to reproduce this for newly created tags. However, I did find one old tag (created in Dec) which did appear in this % encoded manner. I looked in deeper and found out that for some reason the tag identifier was stored in this encoded manner.

I'm not sure why/how it is getting stored in this encoded manner. Here is a simple command to check how it is being stored -

$ nepomukcmd query 'select ?i where { ?r a nao:Tag ; nao:identifier ?i . }'

One simple way to fix this would be to use the genericLabel instead of the nao:identifier. That's what all other applications like Dolphin and Kmail do. I was a little reluctant to use it cause the genericLabel would mean fetching another property which would slow down the kioslave.

Let me think about it. I'll most probably move to the genericLabel.

Git commit d94b9e355fc4a521a408a253de76426d2a6e89d3 by Vishesh Handa.
Committed on 25/01/2013 at 14:53.
Pushed by vhanda into branch 'KDE/4.10'.

Tags kioslave: Use the Tag class internally

We had avoided using the Tag class for listDir cause that would mean n+1
queries when listing all the tags - One for fetching all their uris and
the other to fetch each tag's properties. We could instead just do it in
1 query by fetching all the uris and identifiers in one go.

However, this approach had the drawback that we would display the
nao:identifier, whereas all applications actually show the
nao:prefLabel. Also, we could not display the correct datetime of the
tags.

This approach is cleaner and uses the ResourceManager to handle all the
caching.

M  +25   -97   nepomuk/kioslaves/tags/kio_tags.cpp
M  +1    -5    nepomuk/kioslaves/tags/kio_tags.h

http://commits.kde.org/kde-runtime/d94b9e355fc4a521a408a253de76426d2a6e89d3

I re-open this, because unfortunately this is not fixed and released in 4.10 with slightly different behaviour: 

The problems are now the following: 

tags containing special characters such as umlauts or spaces are correctly displayed in dolphin. However, if you try to open (clicking) or deleting (mark and press delete) them, dolphin gives an error message that the tag doesn't exist. It used the expanded form in the error message, e.g.  white%20space" 

In addition to that, testing is very hard because new created tags containing umlauts are not displayed at all in tags:/   (Maybe a caching issue?) 

I reverted your patch locally and applied mine again, which works fine here so far. Could you please have another look at this? 

You can poke me either here on or IRC (we missed each other there it seems. Feel free to leave a message, I read them in the UTC evening when I get home) if you need additional information or if I can help you testing.

More or less fixed in 4.10.1 for new created tags. The only issue remaining is that old tags that have been created with older versions of dolphin are broken. It would be nice if there was some kind of migration or clean up for those. 

Thanks :)

*sigh* previously (in dolphin) created tags in 4.11 are _again_ broken, fixed by re-creating them (new ones are fine), but by this you of course lose all your previous tags if they contained umlauts or spaces. 

Could someone who still has 4.10 do a  before/after diff, and then maybe provide some update mechanism which safely transfers them from < 4.11 to 4.11? 

Thanks :)

Thank you for taking the time to file a bug report.

The Nepomuk project is no longer included in the KDE Software Compilation. With Plasma 5, we have replaced most of the underlying technology with Baloo and other components. Hopefully this will have addressed your concern.

We encourage you to try out Plasma 5 (+Baloo) and let us know if your problem persists.