https://bugs.kde.org/show_bug.cgi?id=358649
--- Comment #3 from Frank Reininghaus <frank7...@googlemail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
