Hi everyone,

is it possible to configure dolphin, so that I can go back/forward by pressing a mouse button?

My mouse has two thumb buttons. In firefox I can use them to navigate back and forward without special configuration.

I tested it with xev and the buttons seem to send button press events as "Button 8" and "Button 9".

Unfortunately "Configure Shortcuts" dialog doesn't seem to recognize mouse button presses at all.

Is there a way to configure mouse buttons to trigger actions (like back/forward)? Maybe by manually editing a config file?

As far as I know it's not possible (yet) with tools provided by KDE, but you can get this by mapping the mouse buttons to Alt+Left/Right with e.g. xbindkeys. I wrote a tutorial on that some time ago: Mouse shortcuts with xbindkeys (see "Emulate key presses").

There is currently work going on in Qt that will allow Qt to support these buttons, maybe be 4.8 (or maybe later). KDE then has to be extended to support them in the underlying mouse handling code, then KDE applications have to be modified to make use of the buttons, the shortcut system needs to be extended to use mouse buttons, and/or there needs to be a method implemented to map mouse buttons to keyboard buttons. I am not sure how long this whole process will take, but at least there is finally some work being done on it (requests for this functionality go back almost a decade).

TheBlackCat wrote:There is currently work going on in Qt that will allow Qt to support these buttons, maybe be 4.8 (or maybe later). KDE then has to be extended to support them in the underlying mouse handling code, then KDE applications have to be modified to make use of the buttons, the shortcut system needs to be extended to use mouse buttons, and/or there needs to be a method implemented to map mouse buttons to keyboard buttons. I am not sure how long this whole process will take, but at least there is finally some work being done on it (requests for this functionality go back almost a decade).

Qt::XButton1 && Qt::XButton2 is not way for KDE 4.6? ... And in rekonq buttons work without xbinds!

A lot of people seem to make this mistake. XButton1 and XButton2 are the "buttons" for the x-axis, that is the scroll wheel. They have nothing to do with the back/forward buttons.

I am not sure how rekonq does it. It could be possible for KDE to do what rekonq does, but since we have a general Qt-based solution in the works it seems like a waste of time to implement yet another solution in KDE. And considering the Qt solution seems almost done, it would be unlikely another solution could re-written from scratch for KDE before Qt's is available. Rather than duplicating the effort already going into Qt I think the effort would be better served implementing KDE support for Qt's solution so KDE is ready as soon as Qt is.

Sendel is correct, and our shortcut-definition code could be updated to support these two "newer" buttons. ("Newer" in Qt having occurred around April, 2010.) As BlackCat knows, my goal is to do much more -- but getting T&I advice about Qt compiler environments which I don't on my Linux PC have is (ahem!!!) proving to be very difficult. And I've been busy with "real life" for a while, too.

Here's the relevant code snippet. The switch statement cases refer to the button numbers seen in xev, and the translations into qt buttons follow each case directly. In my recently freshened qt clone, it starts near line 4232 of file "qt/src/gui/kernel/qapplication_x11":
buttons = translateMouseButtons(event->xbutton.state);
modifiers = X11->translateModifiers(event->xbutton.state);
switch (event->xbutton.button) {
case Button1: button = Qt::LeftButton; break;
case Button2: button = Qt::MidButton; break;
case Button3: button = Qt::RightButton; break;
case Button4:
case Button5:
case 6:
case 7:
// the fancy mouse wheel.
....

<< In this post, I'm snipped out of lot of "spin speed" compression code
<< which occurs inside this code block. And this code block results in the creation of Qt "Wheel" events: None of these 4 X11/xev "button number" events result in a Qt "button" event of any kind.

Following the code block to translate and compress those "fancy wheel" cases, we have two more cases for "regular" buttons:
case 8: button = Qt::XButton1; break;
case 9: button = Qt::XButton2; break;
}


And so: All four supported wheel directions are supported in Qt as "wheel events", rather than button events. XButton1 and XButton2 are buttons, xev buttons 8 and 9 respectively. Qt is already willing to handle them, but Dolphin (and the current "mouse shortcut manager" would need an update in order to listen for them, and to perform some activity in response.

Webkit was already updated to do this.

hi Richard,

I've been following your progress through the JIRA bug(s) you filed at Nokia. If there is anything I can do, testing etc, please let me know.

Your work is very much appreciated. And when it reaches the masses, you will be king

matthias