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 129643 - Tab management should be standardized
Tab management should be standardized
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkNotebook
unspecified
Other All
: Normal enhancement
: Medium API
Assigned To: gtk-bugs
gtk-bugs
: 573574 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-12-18 21:07 UTC by Fabio Gomes
Modified: 2018-02-10 03:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Fabio Gomes 2003-12-18 21:07:41 UTC
Every tabbed MDI application implements its own different tab management
method. This is extremely confusing and unproductive for users.

Also, applications should be able to assign icons to tabs.

* We could add some icons/buttons to the tab area:

1. "New tab" button: When clicked should tell the application to create a
new tab. The application can choose wether this button is available or not,
because creating a tab manually is not applicable in every application
(think of X-Chat for example).

2. "Close tab" button: When clicked, it should tell the application to
close the currently displayed tab. This button should use the same shortcut
key in every application (Ctrl+W?).

3. "Tab list" button: When clicked, it should display a popup menu listing
the tabs currently open. This is exactly equal to the "Window Menu" applet
of Gnome Panel. It is very important to have a standard shortcut key for
this button in every MDI application (Alt+W?). This would improve the
productiveness of MDI applications, since it would enable users to switch
tabs using the keyboard (Alt+W, then arrow keys, then enter) without
visiting every tab in the way to its destiny (ie. current Ctlr+PgUp/PgDn
approach). Also, it is important that this popup menu, when invoked by the
keyboard, should be displayed near the button and not near the mouse cursor
(just like the gnome panel's Main Menu).

For horizontal notebooks (ie. tabs on top or bottom), the format should be:
[ New ] [ Tab ] [ Tab1 ] [ Tab2 ] [ Tab3 ]       [ Close ] [ List ]

And for Vertical notebooks, the format could be:
[ New ] [ Close ] [ List ]
[ Tab       ]
[ Tab       ]
[ Tab       ]
[ Tab       ]

The icon for "New" is a blank paper.
The icon for "Close" is a "X".
For "List", the icon can be a list with an arrow indicating that a menu
will pop up.

Of course, these icons would be themable by GTK themes.

* A standard customizable context menu on the tabs would be great. It could
have the Close action and some appplication-related actions.

* Applications should be able to choose between a scrolled notebook and a
multi-line notebook.

* The notebook widget should limit the text in the tab's label
automatically when the space is limited.

Maybe we should make distinction between a simple notebook widget used in
preference dialogs and the complex notebook widget used in MDI
applications. Maybe the MDI apps can use a taskbar with buttons instead of
tabs. Hmm.
Comment 1 Fabio Gomes 2003-12-18 21:25:25 UTC
The "New" button is really stupid. This stuff is always application
related. 

About switching tabs with the keyboard:

The current (Ctrl+PgUp/PgDn) approach:
- Requires visiting each tab in the way between the current tab and
the tab that you want to switch to
- The state of the tabs in the way is lost (states as in bug 129643)
- The application needs to render each tab in the way, which is slow

The proposed approach ("Tab List" button):
- Requires less keystrokes when you have more than 3 tabs
- You can go directly to the tab you want
- Is a standard approach (ie. standard icon, standard keybinding, etc)

The two approaches could (should) be combined, because none of them is
a complete solution.
Comment 2 Matthias Clasen 2009-03-01 16:12:48 UTC
*** Bug 573574 has been marked as a duplicate of this bug. ***
Comment 3 Matthias Clasen 2018-02-10 03:25:54 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.