After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 721151 - File chooser should bind mouse-forward/backward
File chooser should bind mouse-forward/backward
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.22.x
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
: 787758 (view as bug list)
Depends on: 739839
Blocks:
 
 
Reported: 2013-12-28 12:02 UTC by Tobias Getzner
Modified: 2018-05-02 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tobias Getzner 2013-12-28 12:02:12 UTC
Currently, the  file chooser doesn't seem to bind the forward/backward mouse buttons for navigation.
Comment 1 Federico Mena Quintero 2014-01-07 20:33:00 UTC
I only have a plain old mouse.  What should those buttons do in the file chooser?
Comment 2 Tobias Getzner 2014-01-08 13:57:41 UTC
I suppose it would be great if forward/backward behave analogously as in Nautilus, i.e. they navigate the tree.

Because of the similarities between Nautilus and the file-chooser, I often intuitively try using the forward/backwards mouse buttons, only to be reminded that they aren't bound.
Comment 3 Federico Mena Quintero 2014-01-09 18:57:49 UTC
Do you mean that the buttons just move the cursor in the file list?  Or do they change directories somehow?

Can you please do the following:

1. Run "xev" from a terminal.

2. Move the mouse inside the resulting window, and press the forward/backward buttons.

3. Paste the resulting output here.  I need to know what keycodes are generated by those buttons.

Thanks!
Comment 4 Tobias Getzner 2014-01-11 17:35:55 UTC
Mouse-Forward:
ButtonPress event, serial 25, synthetic NO, window 0xe00001,
    root 0x2a2, subw 0xe00002, time 35402010, (49,30), root:(50,931),
    state 0x0, button 9, same_screen YES

Mouse-Backward:
ButtonPress event, serial 25, synthetic NO, window 0xe00001,
    root 0x2a2, subw 0xe00002, time 35446539, (42,30), root:(43,931),
    state 0x0, button 8, same_screen YES

May it's possible to unify the button handling with the Nautilus code to ensure that both will behave identical regarding forward/backward navigation in the future. Also I'm not sure the buttons always resolve to 8 and 9. Maybe the Nautilus has something for you in this regard. So far, mouse forward/backward always worked for me in Nautilus no matter which brand of mouse I was using.
Comment 5 Robert Roth 2015-01-02 12:11:22 UTC
I have tested this with several mouses, and all of them use 8 and 9 button codes. I have also reported bug 739839 to declare gtk constants for these buttons, to make sure all the applications use the same codes, as we shouldn't hardcode 8 and 9 in each app we need these. Marking bug 739839 as blocking this bug.
Comment 6 Daniel Boles 2017-10-09 13:09:29 UTC
*** Bug 787758 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Boles 2017-10-09 13:10:12 UTC
See also https://bugzilla.gnome.org/show_bug.cgi?id=777694 for the idea that, rather than just doing up/down, these buttons should invoke yet-to-be-added back/forward actions.
Comment 8 Frank 2017-10-10 00:05:36 UTC
Yes, but could they do up/down for the time being? Up/down and forward/back is not that different in the open/save dialogs, because you usually don’t move around in the directory structure that much, and it’s better than dead buttons.
Comment 9 GNOME Infrastructure Team 2018-05-02 15:53:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/459.