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 377441 - Make notebook arrows scroll the tab view
Make notebook arrows scroll the tab view
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkNotebook
unspecified
Other Linux
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 326953
 
 
Reported: 2006-11-20 17:04 UTC by Vinicius Depizzol
Modified: 2018-12-10 15:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Vinicius Depizzol 2006-11-20 17:04:38 UTC 
Arrows of the too-many-tabs-for-window-width state should behavior like arrows of   menus, allowing auto-smooth-scrolling when the mouse is over it.
Comment 1 Steve Frécinaux 2006-11-27 21:14:44 UTC 
I fully agree.

Having used firefox 2 this afternoon, I can say this behaviour of smooth-scrolling the tabs is way more predictable than the current way the arrows work.

In fact, when you click on the arrow on the side of the tab list, you intuitively expect that the next hidden tab will appear. In practice it doesn't, but the tab next to the current one is selected. This just makes the notebook a pain to use when there are too many tabs to fit in the notebook width.
Comment 2 Nick Treleaven 2008-04-23 13:05:48 UTC 
Please could this issue be looked at, there really is an important usability problem with GtkNotebook for apps like browsers and editors where the user has too many tabs to fit on screen. (I work on the Geany editor and often people on the mailing list complain about the lack of scrolling in the notebook.)

The current switch to tab left/right buttons really are not useful as the user can just click on the tab instead or use a keyboard shortcut - making these buttons scroll the notebook tabs would be much more useful, and perhaps more intuitive for most users.

I think the way Firefox 2 does it is that after scrolling, if the user hasn't selected one of the tabs that has been scrolled in view, and the current tab is no longer visible, then scroll the view back after a timeout to show the current tab on screen.

BTW, perhaps this bug could be renamed to 'Make notebook arrows scroll the tab view' to be clearer.
Comment 3 Matthias Clasen 2018-02-10 05:01:02 UTC 
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 4 Matthias Clasen 2018-04-15 00:13:47 UTC 
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new
Comment 5 Andres Gomez 2018-12-10 15:28:06 UTC 
Reported again at:
https://gitlab.gnome.org/GNOME/gtk/issues/1506