Bug 358649

Thanks for the bug report. Unfortunately, support for middle-clicking toolbar buttons has been removed in KDE Frameworks 5, see the comments in https://git.reviewboard.kde.org/r/118782/. This cannot be fixed in Dolphin unless this is restored in KF5.

Many thanks for your reply, the reasons and your work on this.
Ok, will try and submit a bug/feature request in kf5. Any idea which of the many areas of kf5 this would be attributed to (frameworks-package ?)
I will add a "new tab" button to my dolphin toolbar to workaround this.

(In reply to Terry Barnaby from comment #2)
> Ok, will try and submit a bug/feature request in kf5. Any idea which of the
> many areas of kf5 this would be attributed to (frameworks-package ?)

I'm afraid this is not an easy question to answer. I think the cleanest solution might be to include this functionality in Qt.

kdelibs 4.x had a class KAction that extends the functionality of QAction. This class has a "triggered" signal that tells the receiver about the mouse button that was used, and also about keyboard modifiers such as Shift:

http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKAction.html#a47c884a5a7b9b22555584553fd5552a8

KToolBar::eventFilter(QObject * watched, QEvent * event) watched all events that are delivered to the tool buttons and invoked the corresponding KAction's triggered signal with the correct mouse button.

Like some other kdelibs classes, KAction was deprecated in KF5 and replaced by the corresponding Qt class QAction. In principle, this is good because it removes duplicated code and makes it easier to use and maintain, but unfortunately, QAction only has a "triggered" signal that tells that the toolbar button was clicked, but now with which button:

http://doc.qt.io/qt-5/qaction.html#triggered

Funnily enough, the code that filters middle-click mouse events and tries to create a "triggered" signal with mouse button information still exists in KToolBar in KF5 (kxmlgui framework), but it does not work and generates error messages because QAction does not have a matching signal. It would in principle still work in KF5 if a KAction (which is deprecated, but still exists in kdelibs4support) was used. Dolphin and many other apps use KStandardAction to create most actions though, and it creates QAction objects in KF5.

Un-deprecating KAction in KF5 and using it in KStandardAction would be a solution, but I'm not sure how likely this is to happen. It might be better to add this functionality to QAction, and also move the code that handles middle clicks from KToolBar to QToolBar. This might not be easy either because one could argue that the KAction API that has two different "triggered" signals is a bit odd.

Maybe I will try to start a discussion on the KDE Frameworks mailing list about this, but I cannot make any promises. Even if a way to merge this functionality into Qt is found, it might take a long time until this functionality is available for users.

Many thanks for the comprehensive reply, I can see how it will be awkward to fix properly.
I do think this facility should be there though however implemented. Web browsers and other major programs use a middle click on toolbar, links other "icons" to open a new tab etc. and it is inconsistent that kde applications don't (any more). It is a useful desktop productivity feature IMO.
I guess the QAction triggered() signal could pass the QEvent that caused it, giving most flexibility.
But, I assume getting the Qt API changed is much harder and requires much more thought than getting KDE frameworks changed ? In this case changing KDE frameworks first in such a way with a simple KAction that has an API that could be also implemented in Qt's QAction in the future might be best approach ?

Does this same limitation/cause apply to the places menu items (the dropdown menu that appears to the left of the location field when the places sidebar is hidden)?

Mid-button handling in KToolBar has been dropped for good: https://phabricator.kde.org/D7153

I think this should be implemented in Dolphin itself. A simple QAction subclass with an event filter will do the job, but it should be used only for the "Go" actions and not for all the other toolbar actions, imho.

Okay, I can look into this.

(In reply to Kai Uwe Broulik from comment #7)
> Okay, I can look into this.

Is it worth revisiting bug 304589 at the same time?

Git commit 101884841659cf7b1d735e894477415cddd1787f by Kai Uwe Broulik.
Committed on 24/08/2017 at 13:45.
Pushed by broulik into branch 'master'.

Support middle clicking of Back/Forward/Up/Home toolbar buttons

This opens the resulting page in a new tab.

Differential Revision: https://phabricator.kde.org/D7390

M  +1    -0    src/CMakeLists.txt
M  +32   -24   src/dolphinmainwindow.cpp
M  +16   -19   src/dolphinmainwindow.h
A  +58   -0    src/middleclickactioneventfilter.cpp     [License: GPL (v2+)]
A  +50   -0    src/middleclickactioneventfilter.h     [License: GPL (v2+)]

https://commits.kde.org/dolphin/101884841659cf7b1d735e894477415cddd1787f