Peter, from where does the tool bar editor get the text "Stop loading" that is displayed in the bottom display when selecting the "Stop" action?

It looks like it is possible to add some description besides the actual action text. The shortcuts editor could display the same description somewhere.

Ah, this is very interesting - I did not notice this "Stop loading" info at the bottom yet. I just checked the code and "Stop loading" represents the tooltip of the action.

So what would be required is that I add tooltip-descriptions to all those actions and provide a patch for the editor that also shows this tooltips.

I'm reassigning this to me. If you're interesting into improving the editor yourself, I won't object of course ;-)

I'd like to fix this for 4.6, as I think this is really confusing.

Interesting. I was trying to fix the kdelibs side of this bug, and stumbled upon this change [1] which actually disabled displaying the tool tips in the shortcut editor.

Martin, can you explain the reason for this? I would like to replace it with a check "tooltip != text" so it only displays the tooltip on actions that actually have a tooltip set:

Index: kshortcutseditoritem.cpp
===================================================================
--- kshortcutseditoritem.cpp    (Revision 1185458)
+++ kshortcutseditoritem.cpp    (Arbeitskopie)
@@ -98,7 +98,7 @@
     case Qt::ToolTipRole:
         // There is no such thing as a KAction::description(). So we have
         // nothing to display here.
-        return QVariant();
+        return m_action->toolTip() != m_action->text() ? m_action->toolTip() : QVariant();
     case Qt::FontRole:
         if (column == Name && m_isNameBold) {
             QFont modifiedFont = treeWidget()->font();

[1] http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/dialogs/kshortcutseditoritem.cpp?r1=815370&r2=815371

Ah, the commit log says "Remove the useless tooltip", so I am assuming they are only useless because there is usually no tooltip set. Committing the change to trunk in a minute.

The patch from comment #3 does not work as expected because of Qt's internal method that removes the trailing ellipses. We could use the statusTip() instead and display it as the tooltip.

It requires more code, possibly a reimplementation of toolTipEvent() for the tree widget. This is because it keeps displaying the tooltips even when you hover over other items that have no tooltip, which is totally confusing.

The other option is to do what the toolbar editor does: Add a status bar, so it only shows the information when you click on the action. Hovering won't work for "finger devices" anyway (not that we are prepared elsewhere).

Thanks for your investigations Christoph. I hope I don't miss a thing, but wouldn't it be preferable to already add the (optional) tooltip info as part of Qt::DisplayRole?

E.g. currently in Dolphin the actions are shown like this:
Back
Forward
Stop
Date
Date

when returning the tooltip as Qt::DisplayRole if available, it would return this:
Go Back
Go Forward
Stop loading
Sort by Date
Group by Date

Of course we need to check how this looks like in other applications (e. g. probably they use more lengthy tooltips).

I'm not sure though...

This does not only affect the shortcuts. I also have e.g. that doubled "date", "group", "link destination", "owner", "path", "permissions", "size" and "type" entries in the list for the toolbar buttons and I don't know which is which until I put both in the toolbar, test and remove the wrong ones. Extra "barrier" is that those entries have no icons.

*** Bug 275810 has been marked as a duplicate of this bug. ***

Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have resolved this bug.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann