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 72101 - Hig should specify a tab implementations
Hig should specify a tab implementations
Product: gnome-devel-docs
Classification: Applications
Component: hig
Other other
: High normal
: ---
Assigned To: HIG Maintainers
HIG Maintainers
Depends on: 116650
Reported: 2002-02-21 05:15 UTC by Dave Bordoley [Not Reading Bug Mail]
Modified: 2020-12-04 18:18 UTC
See Also:
GNOME target: ---
GNOME version: ---

Added MDI-specific notes to tabbed notebooks guidelines. Added guideline that tabs shouldn't change size. (3.99 KB, patch)
2003-07-03 19:26 UTC, Sebastian Rittau
none Details | Review
Tab status indication guidelines (2.06 KB, patch)
2003-07-03 19:59 UTC, Sebastian Rittau
committed Details | Review

Description Dave Bordoley [Not Reading Bug Mail] 2002-02-21 05:15:33 UTC
Tab implementations in the various gnome programs very. For instance the
new gnome terminal uses a different style than galeon does.

 ------   ------
|tab1 x| |tab2 x|

gnome terminal
 ------------------- -------------------
|        tab 1     | |          tab2    |

There should be a detailed specification as to how tabs are to implemented,
including what options should be included for tabs etc.
Comment 1 Seth Nickell 2002-02-21 12:18:58 UTC
widget bug
Comment 2 Luis Villa 2002-03-01 22:06:11 UTC
Last I checked there was a library for this; the problem is not
'specify how it should work', most likely, but 'specify that everyone
should use the stock library' and then fix that. [Not saying this as
bugmaster; just putting on my usability/hacker hat for a bit. :)
Comment 3 Havoc Pennington 2002-03-17 17:08:36 UTC
See bug 75029 as well.

Suggest that the HIG team come up with an overall recommendation, 
including desired GtkNotebook enhancements for GTK 2.4 to be filed 
against GTK, and "best available hack" suggestion for the short term.
Comment 4 Dave Bordoley [Not Reading Bug Mail] 2002-06-20 14:49:33 UTC
ccing marco so we can get a galeon perspective :)
Comment 5 Calum Benson 2002-06-20 17:48:44 UTC
The HIG does suggest (IIRC) that basically you should use tabs so that
they don't take up any more space than necessary, i.e. don't pad them
to fit the width of the window or make them all the same width as each
other.  Unfortunately I don't know what flags you have to set to make
that happen, so I couldn't include that information :)

This of course doesn't cover issues like whether/when to use icons or
coloured text on tabs, which is something we ought to address as well
assuming we have anything sensible to say about it...
Comment 6 Calum Benson 2002-06-20 17:54:01 UTC
Oh, as for "enhancements to GtkNotebook 2.4", I vote for a standard
"something on this tab has changed" indicator, to alert the user to
things like external changes (e.g. channel tabs in xchat) or to
unsaved changes (e.g. in an explicit-apply tabbed preferences dialog). 

This indicator would need to be themable, though, for accessibility
purposes-- just turning the text blue or red or something doesn't
really cut it :/
Comment 7 Dave Bordoley [Not Reading Bug Mail] 2002-06-20 17:57:19 UTC
Basically, I would like to see all tabbed gnome apps act the same.
Have the same file menus, same tab behavior etc. I think we need to be
brutally clear on how apps should behave in regards to tabbing.
Comment 8 Marco Pesenti Gritti 2002-06-20 21:58:10 UTC
Current implementation in galeon2 is to have use a tab size of 1/7 the
window size. But we have also a minimal size to ensure the title is
not unreadable. When you have more then 7 tabs in a window the
scrolling arrows are showed.
Following Calum suggestions about not adding any pad, we could move to
a max size of 1/x of the window instead of a fixed one.
This is also similar to mozilla but I'm not sure how much it would be
good for different types of applications.

I think the "something is changed" proposal is great. We have 3 states
in galeon though, Normal/Loading/Load complete. But this is probably
just galeon specific ... Having this themable would allow us to remove
colors preferences ...

Other issues that could be discussed:

1 Is a Close button on the tab good ?
2 Should tabs be reorderable by drag and drop ?
3 Is a tabs menu needed and which items it should contain
4 How the Close part of the File menu should look for an application
using tabs in the main window ? See 83560
5 Someone seem to be confused by the fact that closing the last tab
close also the window (and doesnt leave and empty window like in real
MDI). I personally prefer current behavior but ...

Just some braindumping.
Comment 9 Marco Pesenti Gritti 2002-06-20 22:35:28 UTC
Hmmm in application like galeon, where the title of the tab is changed
frequently in a not interactive way, you really want to have tabs all
of the same fixed size. Otherwise every title change would cause a tab
resize ....
Comment 10 Calum Benson 2002-06-21 11:25:05 UTC
The resizing point is a good one, it might make more sense to have
different recommendations for tabs with dynamic and static labels.
Comment 11 Murray Cumming 2002-12-10 13:26:42 UTC
I don't see how tab resizing is a problem. I'd prefer it to truncation
of the document title. It would only happen on the current tab, so the
notebook page itself wouldn't jump around at all.

Is there anything that the GtkNotebook defaults don't do that we need,
apart from:
- a standard way to show "unsaved changes"
- a "Close this document" X box.
Comment 12 Murray Cumming 2002-12-24 00:34:26 UTC
Can anyone reply?
Comment 13 Calum Benson 2002-12-24 11:29:17 UTC
I can't think of anything else that's come up any time we've talked
about this, those two features would be a pretty valuable start (and
defining what the 'unsaved changes' indicator should be is probably
enough to be going on with for now).

There are also some related comments in bug #72170.
Comment 14 Murray Cumming 2003-04-04 10:23:57 UTC
So, we'd like an EggNotebookDocuments that adds the [x] to the tabs
and has some kind of
void user_requested_document_close(unsigned int notebook_page)

For me, it would make sense to add a map of
page-numbers-to-document-uri in that widget too.

So, does anyone have any ideas how we might show "unsaved changes"
per-tab rather than just in the window title when the tab is selected?
Let's rule out color changes.
Comment 15 Calum Benson 2003-04-04 10:56:19 UTC
Well, it would be good if the unsaved indicator on the tab was the
same as the unsaved indicator in the titlebar... we don't recommend
anything specific in the HIG for this yet, but just putting an
asterisk before the title is probably the most widely used method at
the moment.
Comment 16 Murray Cumming 2003-05-30 09:02:29 UTC
Comment 17 Dave Bordoley [Not Reading Bug Mail] 2003-05-30 14:01:51 UTC
I just wanted to mention that i'm more convinced than ever that tabs
should be implemented by the wm.
Comment 18 Murray Cumming 2003-05-31 15:12:02 UTC
Yes, Havoc has said that too, I think, in very general terms. But I
have no idea how it might be done. And I don't know if it's a
reasonable expectaction to have of the window manager.

At the moment apps are doing it themselves.
Comment 19 Dave Bordoley [Not Reading Bug Mail] 2003-06-02 01:32:42 UTC

I have some ideas (ok i stole some of them from mpt). Basically it
would require a wm spec extension so that an app could specify that
something should be opened in a tab with the current window. I guess
each window would have an associated tab group.

Windows that are already opened could be tabed by alt+draging the
title bar of one window ontop of another. 
Comment 20 Murray Cumming 2003-07-01 08:55:15 UTC
> Basically it
> would require a wm spec extension so that an app could specify that
> something should be opened in a tab with the current window.

Well, however it's implemented, there is clearly interest in pursuing
it. This isn't really the place for that though.
Comment 21 Sebastian Rittau 2003-07-03 18:46:46 UTC
I will try to summarize the points that were brought up in this bug:

* Drag & Drop support (tab reordering) for GtkNotebooks would be nice.

  => not HIG stuff, discussed in bug 73240 against gtk+

* We should probably have scroll arrows (like in Galeon) when the
number of tabs to display is larger than the available space.

  => filed as bug 116644 against gtk+, patch for the HIG follows

* Tab states: there should be a way to specify different states for
the page of a tab, like "loading", "ready", "unsaved", etc.

  => filed as bug 116647 against gtk+, patch for the HIG for a
(possibly temporary) solution/workaround follows

* Should tabs expand and fill out the whole space reserved for tabs
(like gnome-terminal currently does), should tab labels that don't fit
be clipped? What about tabs that change their labels during the
lifetime of the tab?

  => this is partly in the HIG, patch for clarification and
enhancement forthcoming

* Close buttons. Should they be on the tab itself or at the right of
all tabs? The latter seems not to be possible without gross hack with
current Gtk+.

  => Filed as bug 116650 against gtk+

Missed anything? I made this bug depend on bug 116650. I guess it
could be closed, once this implemented and the attached patches (or
similar recommendations) are applied.
Comment 22 Marco Pesenti Gritti 2003-07-03 18:58:19 UTC
>* Should tabs expand and fill out the whole space reserved for tabs
>(like gnome-terminal currently does), should tab labels that don't fit
>be clipped? What about tabs that change their labels during the
>lifetime of the tab?

I think that for applications that use tab for MDI the mozilla
beahvior is interesting.
Basically the first 4 tabs has a width based on the window size (1/4).
When more tabs are added the size is adjusted dinamically.
This is similar to gnome-terminal behavior but has the advantages:
- To not cause resizes until the window is full
- To not have huge tabs when there are only a few of them

See 116519 for a small discussion about it.
Comment 23 Sebastian Rittau 2003-07-03 19:26:19 UTC
Created attachment 18023 [details] [review]
Added MDI-specific notes to tabbed notebooks guidelines. Added guideline that tabs shouldn't change size.
Comment 24 Sebastian Rittau 2003-07-03 19:33:20 UTC
Just to summarize my last patch (affects "Tabbed Notebooks" in Chapter
6: "Controls"):

* Introductory notes about MDIs
* Tabs shouldn't change size.
* Static tabs: Tabs should be exactly as wide as required (old suggestion)
* Dynamic tabs: Tabs should have a fixed size and labels should be
truncated if necessary.
* Scrolling arrows might be appropriate if number of tabs is not known
in advance.
Comment 25 Sebastian Rittau 2003-07-03 19:59:11 UTC
Created attachment 18024 [details] [review]
Tab status indication guidelines
Comment 26 Dave Bordoley [Not Reading Bug Mail] 2003-07-03 20:02:54 UTC
Well despite the fact that i think most of the hig writers won't want
to add any comments on mdi, i'll add a comment:

I think that both file->close (assuming that there is no quit menu
item as both the draft hig suggest and as is implemented in epiphany)
should only close the current tab, and that the window border close
button should also only close the current tab as well. This prevents
us from recreating the nitemare which is the havoc quit reigns upon
multiple window apps onto tabed mdi apps. Also it is more consistent
with sdi apps, doesn't force the user to think as much, and worst
comes to worst a user can close multiple tabs at once by just
hammering the window border close button with the mouse. 

Also i've heard anecdotal evidence from another ephy dev that when he
let a friend of his use his browser, by providing him with a new tab
to work in, the users first impulse was to close the tab with the
window border button, which could have caused lots of data loss.

ps. i still think this should be done in the window manager and that
tabbed mdi has no place in a well designed document based gui.
Comment 27 Sebastian Rittau 2003-07-03 20:10:04 UTC
On the MDI vs. WM issue: I would probably agree that a change to
existing WMs is the appropriate solution(although I haven't pondered
about this very much, yet). But as it stands, MDI is very convenient
for a limited set of applications (like web browsers or terminal
windows). Since there no solution on the WM front in sight, I think
that we must consider MDI for now. Nobody is forcing us to commit to
MDI forever.
Comment 28 Dave Bordoley [Not Reading Bug Mail] 2003-07-03 20:24:42 UTC

I think the HIG should push the envelope when it comes to ui, not
stick to what is currently possible. I think there are a lot of
examples from the past year and a half that suggest that HIG
recomendations lead to change. (we do have reason to believe this, see
the bold label frames, the button ordering etc.) If the HIG strongly
states that any type of tab mdi should be implemented by the window
manager and any required extensions to wm spec, I believe we will
sooner see a tabbed wm because devs will ask for it.

That said maybe a gup approved document on the current state of tab
mdi might be acceptable for the time being, but I don't think it
belongs in the HIG personally (even though I'm the one that opened
this bug :)
Comment 29 Murray Cumming 2003-07-15 12:01:10 UTC
Well, if you can describe exactly what should happen (even just
exactly how it would look and act) then that will do more than
anything to help make it happen.
Comment 30 Calum Benson 2003-11-26 17:49:15 UTC
I've just applied Sebastien's patch as a placeholder in the HIG for
any more concrete recommendations on this topic. Except that I used
preference windows as an example, rather than 'MDI' :)
Comment 31 Luis Villa 2004-04-28 04:29:46 UTC
Comment on attachment 18024 [details] [review]
Tab status indication guidelines

Marking committed based on calum's last comment on the bug.
Comment 32 Sebastian Rittau 2004-05-01 13:09:58 UTC
Comment on attachment 18023 [details] [review]
Added MDI-specific notes to tabbed notebooks guidelines. Added guideline that tabs shouldn't change size.

This patch hasn't been committed yet.
Comment 33 Thilo 2005-12-22 12:47:03 UTC
Hi, I have just created a wiki page at

for this topic that may better reflect the current status in future.
Comment 34 Calum Benson 2006-11-27 16:04:37 UTC
See also
Comment 35 Christian Neumair 2008-07-23 08:48:24 UTC
We still do not have a policy, and now we have tabs in Epiphany, Nautilus, gedit, gnome-terminal etc. Raising priority to high.
Comment 36 Allan Day 2008-10-12 22:39:31 UTC
One thing that seems to have been ignored in previous discussions about tabs on Bugzilla is where new tabs are placed. Epiphany inserts new tabs to the right of the current active tab. Gedit and Gnome Terminal, on the other hand, append new tabs at the far right-hand side. IMO, Epiphany gets it right, but yes, the important thing is to have a consistent approach.
Comment 37 Reinout van Schouwen 2008-10-21 11:25:33 UTC
(In reply to comment #36)
> One thing that seems to have been ignored in previous discussions about tabs on
> Bugzilla is where new tabs are placed. Epiphany inserts new tabs to the right
> of the current active tab.

It only does so when you have activated the Tab Groups extension (or you're using a very old Epiphany version). The default behaviour is to add tabs to the far right.

Comment 38 Allan Day 2008-10-21 16:28:23 UTC
Reinout - yeah, it's the Tab Groups extension. Thanks for the clarification. This behaviour - having the new tab placed next to the current one - is excellent, IMO.
Comment 39 Calum Benson 2010-03-05 17:58:49 UTC
Setting target to 3.x, and adding 'uipattern' to whiteboard as one or more patterns could fall out of this for our (proposed) 3.x UI pattern library.
Comment 40 Calum Benson 2010-03-05 18:44:13 UTC
See also bug #607886, where 'close tab on Ctrl-middle-click' is proposed.
Comment 41 Calum Benson 2011-03-02 12:50:39 UTC
See also Bug 83265, where there is a suggestion to show keyboard shortcuts in tab labels when tabs can be switched using Alt+Number.
Comment 42 Allan Day 2014-09-26 11:09:01 UTC
The HIG now contains a page on tabs. It could do with more elaboration, but it is a start. Please file bugs for any specific additions that are required.