[Nepomuk] Usability Issue - Never displaying the Nepomuk URI

[Vishesh Handa]

Hey everyone

This week I have been working on improving the Nepomuk kioslaves, and I've
encountered a problem with Dolphin (and Konqueror). The problem is
explained in quite detail in this bug report [1]. The basic problem is that
the user should never see "nepomuk:res/uuid". It's the internal name of the
resource and it should not matter to the user.

The problem comes when opening nepomuk uris via the nepomuk kio slave. For
example - The user searches for "Coldplay" (via krunner) and gets a
"Contact" which they select. This gives them a url of the form
'nepomuk:/res/adfafadf', and opens it with the file manager. Dolphin then
displays this URL via the nepomuk kio slave, and the files related to
"Coldplay" are shown.

The problematic part is that the window title (and tab name) are displayed
as "nepomuk - res/uuid", which is ugly. I checked and the UDS_DISPLAY_NAME,
is set to "Coldplay". But Dolphin operates only on URLs.

Here is the relevant code -

// dolphinmainwindow.cpp:2025
QString DolphinMainWindow::tabName(const KUrl& url) const
{
    QString name;
    if (url.equals(KUrl("file:///"))) {
        name = '/';
    } else {
        name = url.fileName();
        if (name.isEmpty()) {
            name = url.protocol();
        } else {
            // Make sure that a '&' inside the directory name is displayed
correctly
            // and not misinterpreted as a keyboard shortcut in
QTabBar::setTabText()
            name.replace('&', "&&");
        }
    }
    return name;
}

This clearly only operates on the URL instead of the UDS Entries. Would it
be a big change to stat the url and then use the display name? (
KFileItem::text() ? )

Or does anyone have any other suggestions on how to improve it? I could
possibly redirect the url to the nepomuksearch:/ url (which it actually
does internally via the ForwardingSlaveBase), so that a proper name is
shown? I'm not sure.

Opinions?

[1] https://bugs.kde.org/show_bug.cgi?id=287259

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121128/183c4cf6/attachment.html>